我目前正在考虑为我的一个托管项目建立一个新的基础设施。基本上它将是托管式托管，重点关注基于 Django 的应用程序。当然，所有这些都将基于 Linux，以 PostgreSQL 作为数据库，以 nginx 或 Apache 作为 Web 服务器，以及 GUnicorn 等。
现在我正在市场上寻找服务器系统租赁，很难找到符合预算和所有标准的系统。所以我想就以下问题寻求建议。
我能找到的所有好产品要么使用单个高端 XEON E3-12xx（四核 @ >= 3.2Ghz），要么使用多核 Opterons（6000 或更老的处理器，8 个或更多核心 @ 2.00 - 2.40 GHz）。从 I/O 的角度来看，两者通常都具有带电池的 HW-RAID10、足够的 RAM 来满足我的需求（24-32 GiB ECC-RAM）和 1 Gbit/s 上行链路。我发现的一个产品也相当不错，但它基于两个 E5620 XEON，在我看来它们相当过时，而且该系统的价格与其他系统相同。
现在我很纠结。在我见过的所有综合基准测试中，XEON 的表现都比 Opteron 好得多——重点是综合基准测试。但我坚信，当涉及到服务器工作时，多核确实会带来很大的好处，因为服务器需要并行执行更多工作（例如，上下文切换成本也更低）。但是，由于每个核心相差 1 Ghz 或更多，我不再那么确定了，因为就我而言，我正在比较不同的微架构（XEON 与 Opteron）和不同的代。
因此我想问一下社区：对于以应用程序为中心的 Web 服务器并且还必须处理数据库负载来说，是使用较低速率的较多核心还是使用较高速率的较少核心？
邮件系统是另一回事。理想情况下，我希望将邮件、数据库和网络放在三个不同的服务器上。但目前预算不够。因此，根据我为网络服务器获得的系统，邮件系统也有可能最终放在该系统上……我知道这不是最理想的。我担心的是邮件系统的所有小写入会对数据库和网络性能产生多大影响。例如，使用 32 GiB 的 RAM，在不久的将来，数据库将完全放在 RAM 中，直到服务大幅增长（如果有的话）。
一种可能（或多或少是最优的）情况：Web 和 DB 位于 8 核 Opteron 62xx @ 2 Ghz 盒上（其他一切如上），邮件系统位于较小的 E3-1230 上。但我再次非常担心 Opteron 的性能。:(
这是一个艰难的决定。再次，我将非常感激任何能得到的建议/帮助。
提前谢谢您...
更新（2011 年 11 月 8 日 @ 1518 GMT）：基本上，我正在将 Sandy Bridge E3-12x0 XEON 与 Magny-Cours/Zurich/Interlagos Opterons 进行比较。不幸的是，我无法获得基于 Ivy Bridge 的专用服务器。根据 apache 基准测试和 cpubenchmark.net 结果，E3-1270v1 似乎是一台真正的主力，其性能甚至超过双 E5620 和大多数 Opterons，这有点令人难以置信。当然，大多数测试仍然是综合性的，还有其他瓶颈需要考虑。但在这个阶段，我想为未来打下坚实的基础，所以我不会太容易受到 CPU 的限制。
我的直觉一直是，对于 Web/DB 服务器来说，应该使用更多内核和/或处理器，而不是以牺牲内核/处理器数量为代价来提高时钟频率。因此，以 E3-1270 为例，4C 设置似乎是一个错误的做法。
顺便说一句，托管服务是我向客户提供的产品，因此它不是我可以进行基准测试的单一产品。基本上，它几乎总是基于 Django 的应用程序，主要是具有自定义功能或自定义项目的 CMS 系统。
现在，我真正考虑的是将一个不错的 E3-1270 系统用作组合 Web 和 DB 服务器，将一个 E3-1220 用作邮件系统。两者都具有快速 RAID 和充足的 RAM。不过，我仍然相当担心真正的 4C 很快就会在生产环境中造成问题。 :( 但是，如果我得到一个基于 Opteron 6274 的系统，我还必须在该系统上运行邮件系统，这不是很理想。此外，根据 cpubenchmark.net 的说法，它并没有快太多……但再次：综合基准。 :(
基本上，我问的是：在实际场景中，例如 Opteron 6274 或 2x 6128 是否会胜过 E3-1270，还是 E3-1270 仍会获胜？这是打下坚实基础的正确决定吗？
再说一次，如果有人能给我任何好的建议和/或意见，我将非常感激，因为我现在陷入了大脑中的反馈循环中。:)
更新（2011 年 12 月 8 日 @ 1835 GMT）感谢大家的帮助。现在我正在研究一种完全不同的方法：将客户的项目等托管在 Heroku 或 Google AppEngine 上，从而提前避免大部分麻烦。;) 对于邮件系统，E3-12x0 就完全足够了，所以我会使用组合的 web/app/db 服务器来省去所有的麻烦，毕竟最终它的可扩展性不强。我必须做进一步的研究，看看这是否可行，没有任何重大限制……但我充满希望。:)
答案1
您的问题不仅仅涉及核心和性能。
- 您的服务器需要支持多少个并发用户？
- 您是否只有一台服务器且没有冗余？您的应用程序可接受的停机时间是多少？
- 您是否对该应用程序的开发机器进行过任何基准测试，以在一定程度上推断性能？
如果您预计流量不会太大，那么您可能过于担心。如果您想将所有应用程序放在一台服务器上，那么一旦硬件出现问题，您就会面临完全中断的风险。看看您是否可以使用 2 倍低端机器并分配负载。为了提高性能，您可以使用任务集将核心专用于 PostgreSQL 进程，以便数据库性能可控。
如果你管理好磁盘，那么你也可以获得更好的性能。例如，为 pg_xlog 设置 RAID 1 中的 2 个磁盘。
长话短说，对您的应用程序进行基准测试，如果您无法承受停机时间，请考虑冗余。此外，将成本与云解决方案进行比较，如果您的应用程序可以扩展，这将有所帮助。
答案2
这是一个复杂的主题，但不要忘了这里还有另一个元素——你还可以比较不同代的硬件。这不仅仅是一个纯粹的 GHZ 比较，你完全可以将过时的 Opterons（只有 8 个内核？- 那是 2x4，与今天相比，这是一个非常慢的内核）与 Sandy Bridge / Ivy Bridge 级别的 Xeon 进行比较。我会选择 Xeon，仅仅是因为代际问题。
（是的，我有同样的 - 1 个四核现代至强处理器和 1 个双皓龙处理器，带有 2 个 4 核插槽，而至强处理器的整体性能压垮了更大的机器，很快就会被重新用作 SAN 系统。
答案3
内核越多，您就能处理更多客户端，同时减少上下文切换，理论上可以弥补时钟速度的差异。缺点是，在使用率较低时，系统运行效率会降低。
答案4
不要扩大规模，要缩小规模！
我从您的问题中了解到，您预计您的 Web 服务器将承受大量工作负载，例如点击量。由于您可能没有关于实际托管的内容、静态内容和动态内容的详细信息，如果是动态内容，则使用哪种技术（java、C#、Python 或 PHP），因此目前除了可扩展之外，无法提出其他解决方案。
我的建议是？使用相对便宜的硬件组成的 LB 集群，在需要时可以进行扩展。不要将所有东西都放在一台要么规模过大（昂贵）要么规模过小（性能损失）的机器上。但要允许自己从小处着手，并在流量增长时进行扩展。
因此，负载平衡实际上就是您正在寻找的答案。