负载测试中IIS服务器无法达到预期吞吐量的技术问询

嘿，我来帮你捋捋这个吞吐量上不去的问题！既然服务器的CPU、内存、磁盘、网络都没跑满，说明瓶颈大概率藏在IIS、应用或者数据库的配置细节里，咱们一步步排查：

• 打开applicationHost.config（通常在C:\Windows\System32\inetsrv\config），找到system.webserver/serverRuntime节点，检查这几个关键参数：
  • maxConcurrentRequestsPerCPU：默认可能是500，直接调到1000+试试
  • maxConcurrentThreadsPerCPU：默认20，改成200左右
  • maxConcurrentConnections：默认是4294967295（理论上限），但如果是HTTP/1.1，实际受限于客户端连接数，不过先确认这个值没被改小
    改完记得重启IIS，用命令iisreset就行。
• 再看应用程序池的队列长度：默认是1000，要是请求排队了但服务器资源还空着，不妨调到2000，不过别太夸张，避免线程池过载。

• 打开项目的web.config，找到httpRuntime节点，调整这些参数（按每CPU来算，你的服务器是16核，所以数值可以对应放大）：

  <httpRuntime maxWorkerThreads="100" maxIoThreads="100" minFreeThreads="88" minLocalRequestFreeThreads="76" />
  

  这些参数是确保有足够的空闲线程处理新请求，避免线程池饥饿。
• 重点排查异步代码阻塞：比如在异步方法里用.Result或者.Wait()，这会把异步线程卡成同步，导致线程池里的线程被占着不放，看起来服务器资源没满，但请求处理效率极低。可以用Visual Studio的性能探查器看看线程池的线程状态，有没有大量等待的线程。

• 虽然SQL的CPU和内存没跑满，但可能是逻辑瓶颈：
  • 抓慢查询：用SQL Server Profiler或者Extended Events，看看有没有执行时间超过几百毫秒的语句，大概率是缺少索引或者查询写得太烂。
  • 检查数据库连接池：应用的连接字符串里有没有设置Max Pool Size？默认是100，要是并发请求多，连接池不够用会导致请求卡在“等连接”上，这时候SQL资源没满，但吞吐量上不去。可以把Max Pool Size调到200试试。
  • 看等待统计：运行SELECT * FROM sys.dm_os_wait_stats ORDER BY wait_time_ms DESC，看看有没有大量的LCK_M_*（锁等待）或者PAGEIOLATCH_*（页IO等待），这些都是隐性的性能杀手。

• 你的WPF测试工具会不会拖后腿？比如它的并发线程数设得不够，或者请求发送的逻辑有问题（比如同步发送请求，导致测试服务器的线程被占满）。可以换个专业工具比如JMeter跑一次负载测试，如果专业工具能达到预期吞吐量，那就是你的WPF工具的问题，得优化它的并发逻辑。
• 检查测试服务器的端口耗尽：Windows默认临时端口是49152-65535，要是并发请求太多，TIME_WAIT状态的连接占满了端口，新请求就发不出去。用netstat -ano | findstr TIME_WAIT看看数量，要是太多，可以改注册表的TcpTimedWaitDelay（设为30）和MaxUserPort（设为65535）来优化。

• 看IIS日志：有没有大量的5xx错误或者请求超时？这些都会拉低有效吞吐量。
• 开启动态压缩：如果返回的内容是文本（HTML、JSON、XML），开启IIS的动态压缩能减少网络传输时间，而且你CPU没瓶颈，完全可以开。
• 启用HTTP/2：HTTP/2的多路复用能让单个连接处理多个请求，比HTTP/1.1效率高很多。IIS里可以通过“添加角色和功能”开启HTTP/2，记得绑定HTTPS证书（HTTP/2通常需要HTTPS）。

内容的提问来源于stack exchange，提问作者John L.