bze*_*ero 19 java multi-threading
我不确定 serverfault 是否适合问这个问题，但我想知道如果您必须为 Java Web 应用程序选择新的 CPU 类型，您会做出什么选择：
a) 具有 32 个内核和时钟速度 2.5 Ghz 的 CPU
或者
b) 具有 8 个内核但时钟速度为 3.8 Ghz 的 CPU
鉴于 Web 应用程序的每个传入 HTTP 请求都由一个免费的 Java 线程提供服务，选择 a) 可能是有意义的，因为您可以同时处理四倍多的 HTTP 请求。然而，另一方面，CPU b) 可以更快地完成单个 HTTP 请求的处理......
你怎么认为？
旁注：
小智 29
tldr; 真正的答案可能是“更多 RAM”，但正如您所问的那样，答案当然是视情况而定。再说一次，32 核@2.5Ghz 几乎肯定会击败 8 核@3.8Ghz - 它是内核的 4 倍，而时钟速度快 1.5 倍。不是很公平的战斗。
您应该考虑的几个因素是事务响应时间、并发用户和应用程序架构。
事务响应时间 如果您的 Java 应用程序在几毫秒内响应大多数请求，那么拥有更多内核来处理更多并发请求可能是可行的方法。但是，如果您的应用程序主要处理运行时间更长、更复杂的事务，它可能会受益于更快的内核。（或者可能不会 - 见下文）
并发用户和请求 如果您的 Java 应用程序收到大量并发请求，那么更多的内核可能会有所帮助。如果您没有那么多并发请求，那么您可能只是为一堆额外的空闲内核付费。
应用程序架构 如果应用程序服务器花费大部分事务时间等待来自 Web 服务、数据库、kafaka/mq/等的响应，那么我提到的那些长时间运行的请求将不会从更快的内核中受益。我见过很多具有 20-30 秒事务的应用程序，它们的响应时间只有一小部分用于处理应用程序本身，其余时间则等待来自数据库和 Web 服务的响应。
您还必须确保应用程序的不同部分能够很好地结合在一起。让 32 或 64 个线程分别处理一个请求，所有线程都在排队等待 JDBC 池中的 10 个连接之一，也就是 Python 问题中的小猪，这对您没有多大好处。现在进行一些规划和设计将为您节省大量的性能故障排除工作。
最后一件事 - 您可能会比较哪些 CPU？我发现最便宜的 32 核 2.5 GHz CPU 的成本至少是任何 8 核 3.8 GHz CPU 的 3 或 4 倍。
假设您的 Java Web 服务器配置正确，您应该选择更多内核。
仍然存在依赖关系，例如信号量、仍然有一些线程在等待的并发访问，无论内核数量或速度如何。但是由 CPU（内核）管理比由操作系统（多线程）管理要好。
无论如何，32 核 @2.5Ghz 将处理更多线程，并且比 8 核 @3.8Ghz 更好。
此外，CPU 产生的热量取决于频率（除其他外），这不是线性的。意思是，3.8Ghz 会比 3.8/2.5 x 产生更多的热量（必须根据您的确切 CPU 类型/品牌进行确认……许多站点提供详细信息）。
你告诉我们 a 请求大约需要 100-200 毫秒来执行，而且它主要是处理时间（尽管很难将实际的 CPU 执行与实际的内存访问分开），很少的 I/O，等待数据库等
您必须对两个 CPU 中的每一个实际花费的时间进行基准测试，但假设在较慢的 CPU（具有 32 个内核）上花费 150 毫秒，在较快的 CPU（只有 8 个内核）上花费 100 毫秒。
那么第一个 CPU 每秒最多可以处理 32/0.15 = 213 个请求。
第二个 CPU 每秒最多可以处理 8/0.1 = 80 个请求。
所以最大的问题是：你期望每秒有多少请求？如果您每秒处理的请求远不及数十个，那么您不需要第一个 CPU，第二个 CPU 将为您提供更快的每个请求的执行时间。如果您每秒确实需要超过 100 个请求，那么第一个是有意义的（或者拥有多个服务器可能更有意义）。
请注意，这是非常粗略的估计。唯一确定的方法是用实际负载对每个服务器进行基准测试。如上所述，快速 CPU 或具有大量内核的 CPU 会很快变得无法访问内存。各种 CPU 缓存的大小在这里非常重要，以及每个请求的“工作集”。这是考虑真正受 CPU 限制的工作，没有系统调用，没有共享资源，没有 I/O……
| 归档时间： |
|
| 查看次数： |
3987 次 |
| 最近记录： |