在许多企业系统体系结构中，根据并发性工作负载要求来调整硬件大小已势在必行。大多数产品供应商将提供他们自己的硬件规模表，其中你只需插入指标，它会抛出服务器数量，RAM所需的细节等等。但是，当系统使用开源软件组件开发时，这样的指南并不容易获得。硬件规模 - 拇指规则
我需要做一个系统的硬件大小。该系统可水平扩展，因此可通过添加更多节点来适应不断增长的流量。首先，系统将有两个HAProxy负载平衡器节点。负载平衡器后面是提供HTML页面和JavaScript的Web服务器。有更多节点托管RESTful Web服务的服务器。在后端有一些Cassandra节点。我们对流量或并发用户有一个粗略的想法。
硬件尺寸选择应该如何？有没有一般的指导方针？
这也许是最难回答的问题之一。我正在关注这个主题，看看其他人可能会有什么想法。
需要考虑产品运行的硬件平台，操作系统，应用程序服务器，数据库服务器等，以及产品的相对复杂性。提供静态HTML的网站将扩展到比OLTP系统更多的用户。
了解目标平台的先天功能至关重要。知道ASP.NET支持12个并发执行的线程/ CPU（默认配置），你可以使用输出缓存来大大降低并发性，或超过3,000请求/秒需要千兆以太网到数据库服务器等，可以帮助你正确地计划，知道你必须拉动什么杠杆等。
供应商硬件尺寸表反映了他们花在产品性能和容量测试上的大量工作。对于您正在进行内部开发或非营利开发的应用程序，这可能是一个难题。
总之，您的目标应该是开始制作产品中更复杂区域的POC，然后开始投资于持续的性能和容量规划迭代。
如果不这样做，可能会发生故障 - 无法执行，无法执行容量规划或业务失败 - 用户从未到过。
我希望我有更好的答案 - 我自己也面临着同样的挑战。
如果您有第一天就无需部署到所有1,000个用户的奢侈品，那么我很乐意使用虚拟化来帮助您解决这个问题。我首先用裸机建立服务器，并根据需要检查它们的功能。然后使用你喜欢的任何虚拟机软件的P2V转换器从物理转换为虚拟磁盘映像。然后，我会删除服务器的原始磁盘并安全地存储它们，在里面粘贴一些新的磁盘，安装您选择的虚拟机管理程序，添加转换后的虚拟机，启动它，为您的虚拟机/操作系统添加para工具并查看您的工作方式。如果你的服务器工作，那么你给自己的是可移植性。您可以从一百名左右的用户开始，测量负载，推断并做出一些假设。然后添加更多用户，测试您的假设等等。如果你有1,000个用户，并且有足够的空间可以做到这一点，那么你可以留在虚拟环境中（优点：良好的灾难恢复选项，便携性;缺点：你失去了一些性能），或回到裸机版本处理工作。如果您的机器变得越来越热，那么您可以非常轻松地将VM移动到更大/更好/更快的硬件，或者将VM复制到另一个物理VM主机和群集。
我知道这并不直接回答你的问题，但我不确定这是否有经验法则，因为基于如此多的因素，每用户负载有巨大的波动。
如果你有一个月左右的时间，直到你不得不订购你的服务器，你可能会考虑新的基于Nehalem的Xeons - 他们真的值得等待。
下列几点可以帮助你
由于Chopper3