IIS并发优化.md

1. 网上提到的修改队列长度以及请求连接数，都试过发现没有什么作用，本身只要进入队列排队，那便处于阻塞状态，响应超过10秒无法忍受，加之要让运维的同学手动配置，他们也不愿意，所以就按默认配置即可。
2. 在服务器资源满足的情况下，调整IIS应用程序池的最大工作进程效果比较明显。（推荐）
3. 应用自身实现session共享，否则不可用此方案。

---

以下通过本地虚拟机测试，在并发1000的情况下，最大工作进程增加至50，队列方才降下去，服务也恢复正常响应，但是真正上生产服务器时，发现IIS最大工作进程数只需要配至15即可达到虚机的效果。

见第三点，生产服务器压测结果。

---

Windows自带的性能监控Performance Monitor

打开性能监控：cmd->perfmon.msc

性能计数器，监控IIS应用运行情况：
Web Service/Current Connections 监控某个应用程序池来指示当前该应用程序池的连接的数量。
ASP.NET Apps v4.0.30319/Requests Executing 监控所有的 ASP.Net 4.0 正在处理中的请求数量。
ASP.NET v4.0.30319/Requests Current 与上述类似用于监控 Asp.Net 4.0 正在处理中的请求数量。
HTTP Service Request Queues/CurrentQueueSize 用来监控某个应用程序池当前队列中请求的个数。

准备工作，.net写个sleep(1000*3)，模拟网页加载。使用siege进行压力测试，通过配置IIS应用程序池，看web运行情况。

image.png

// 发起1000并发，持续5000s
siege -c 1000 -t 5000s http://11.13.48.188:8888/f5.ashx

1. IIS单个工作进程下

当最大工作进程数默认为1时，应用完全处于不可用的状态。

image.png

2. IIS多个工作进程下

当把最大工作进程数增加至50，每个请求基本秒开。从性能监控器看，列表数、当前连接数都降下来了，说明达到了负载的效果。

image.png

Transactions:               2755 hits
Availability:              70.84 %
Elapsed time:              26.47 secs
Data transferred:           0.56 MB
Response time:              4.85 secs
Transaction rate:         104.08 trans/sec
Throughput:             0.02 MB/sec
Concurrency:              505.04
Successful transactions:        2755
Failed transactions:            1134
Longest transaction:           16.47
Shortest transaction:           3.06

3. 生产服务器压测

服务器配置信息

在以上服务器配置下压测：
1）并发数设置为1000、最大工作进程数要求为15~20，可以达到预期；
2）并发数设置为2000，最大工作进程数为20，无法达到预期，延迟5-10s。
3）直接调整最大工作进程数至50，调整并发数为2000和5000，响应时间基本一致。

并发5000下的数据报告
5000 vs 2000

在IIS最大工作进程数50，并发5000下，服务器内存已爆，查看进程w3wp.exe，平均每个占用100M，50个差不多要5G内存，但从响应结果来看，5000的请求数还未达到该配置峰值，应该可以支持的并发数更高（不再测试，个人电脑扛不住了）。

后续增加服务器内存至16G，对实际生产活动进行监控。

参考：
http://blog.51cto.com/5634716/1742696
http://www.cnblogs.com/dudu/archive/2013/06/08/iis_webserver_settings.html
http://blog.chenxu.me/post/detail?id=98637613-2f8c-4ceb-bfef-c039fefa75fb