我在以下服务器配置上运行大规模ERP系统。该应用程序是使用AngularJS和ASP.NET 4.5
开发的Dell PowerEdge R730（四核2.7 Ghz，32 GB RAM，5 x 500 GB硬盘，配置RAID5）软件：主机操作系统是VMWare ESXi 6.0两台VM在VMWare ESXi上运行..一台是Windows Server 2012 R2，带有16台已分配的GB内存...这包含带有我的应用程序代码的IIS 8服务器另一个VM也是带有SQL Server 2012的Windows Server 2012 R2和分配的16 GB内存....这只包含我的应用程序数据库。
您看，我将应用程序服务器和数据库服务器分开以实现负载平衡。
我的应用程序包含一个注册模块，其中负载预计非常高（10分钟内大约10,000名访问者）
为了支持这一批请求，我在IIS服务器中完成了以下操作 - ＆gt;将应用程序池长度中的请求队列增加到5000 - ＆gt;为aspx文件启用输出缓存 - ＆gt;在IIS服务器中启用静态和动态压缩 - ＆gt;将每个应用程序池的虚拟内存限制和私有内存限制设置为0 - ＆gt;将每个应用程序池的最大工作进程增加到6
然后我使用gatling在我的应用程序上运行负载测试。我一次向注册模块注入了500个用户。
但是，我发现只有40％/ 45％的RAM被使用。每个工作进程最多只使用130 MB左右。
gatling报告说，我的请求中有大约20％的错误是403错误，超过60％的HTTP请求都有超过20秒的响应时间。
单个用户在大约3分钟的时间内发出380个HTTP请求。单个用户的总数据传输量为1.5 MB。我模拟了500个像这样的用户。
我的服务器调整中是否有任何遗漏？我已经调整了我的应用程序代码，以最大限度地减少内存泄漏，增加超时等等。
答案 0 :(得分：1)
我想您收到的答案的第一个警告是，如果您的服务器不支持 NUMA/使用对称处理，您将不会在 CPU 下看到那些 IIS 选项，但上面的海报似乎了解更多比我做的机器。抱歉，我没有足够的街头信誉来将此添加为评论。就 IIS 而言，您可能还想确保您的应用程序池不使用默认回收条件，并选择午夜之类的时间进行回收。如果您应用了根级别设置，则默认应用程序池在 29 小时内回收也可能会针对您的子池触发垃圾收集/导致延迟，即使在并发 gc 中，听起来您可能会从 Gcserver=true 中受益。不过很难评估。
您的 SQL Server 是否针对此类工作负载进行了优化？如果您的数据不是最重要的，您可以通过延迟持久性来缩短执行时间，然后评估为异步 io 等待类型返回过多信息的查询。一般来说，这里并不足以真正评估 sql 优化，但如果配置不正确（大小/增长选项），您可能会因增长、vlf 碎片等而遇到很多超时。