Web 服务器容量规划：更多内核与更多内存
我们有一个 ASP.NET 项目（大约 40 个 Web 表单、50 个表、相当标准的 IO 内容，并尽可能减少），很快就需要部署。 系统上大约有 100 个并发用户，但任何时候只有大约 20 个用户在使用它。 我们最初将其部署在 32 位 Windows Server 2008 上。
在考虑生产服务器规格时，我们应该更担心哪个，是获得更多内核和更少内存（例如 4 核和 4MB），还是获得更多内存和更少内核（2 核和 8MB）？
升级到 Windows Server 64 位是否有助于提高内存利用率？
We have an ASP.NET project (40 or so Web forms, 50 tables, pretty standard IO stuff with care taken to minimize when possible) that will soon need to be deployed. There will be about 100 concurrent users on the system, but only about 20 at any one time will be pounding on it it. We'll be deploying it on Windows Server 2008, 32-bit initially.
When considering production server spec which should we worry more about, getting more cores and less memory (4 cores and 4mb, for example) or more memory and less cores (2 cores and 8mb)?
Would bumping up to Windows Server 64-bit help with memory utilization?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
32 位 Windows Server 只能寻址 ~3GB 内存。 获取 64 位、2 核和 4GB。 或者，如果钱不是问题，可以选择 8 核和 24GB。 重点是永远不要猜测。 如果你猜你就错了。 监控内存压力和 CPU 负载，并根据需要购买更多/升级。 尝试猜测性能瓶颈是什么是不可能的，也是愚蠢的。 唯一的方法是衡量、衡量、衡量并据此做出反应。
32-bit Windows Server can only address ~3gb of memory. Get 64-bit, 2 cores and 4gb. Or if money isn't an issue, get 8 cores and 24gb. The point is to never guess. If you guess you will be wrong. Monitor the memory pressure and cpu load, and buy more/upgrade as necessary. It's impossible, and foolish, to try to guess what will be the performance bottleneck. The only way is to measure, measure, measure and respond according to that.
未包含的一项重要信息是数据库将保存多少数据以及每个用户将使用多少数据。 这将决定您需要多少缓存，以及它是否全部适合缓存，或者您是否会更多地访问磁盘。
利用率？ 仅当您的内存容量大于 3.5GB 时。 如果有 20 个同时活跃用户，您将需要全部 4 个核心和相当大的缓存，因为您最不想要的就是一个活跃用户数据从缓存中刷新以加载另一个活跃用户数据，而只需访问磁盘当第一个用户采取下一个操作时获取他们的数据，从缓存中发送另一个活跃用户的数据......（阅读：颠簸）。
One important piece of information that is not included is how much data the databases are going to be holding and how much each user will be utilizing. That will determine how much cache you're going to want, and whether it will all fit in cache or if you're going to be hitting disk a lot more.
Utilization? Only if you're shooting for >3.5GB of ram. And with 20 simultaneous active users, you're going to want all 4 cores and a sizable cache, because the last thing you want is one active users data being flushed from cache to load another active users data, only to have to hit the disk to get the first users data when they take their next action, sending another active users data from cache... (read: thrashing).