456主机测评
这里再简单描述一下这个问题：我们的图片站点（静态文件）迁移至云服务器后，在iis并发连接数达到3500左右的时候，出现了响应速度奇慢的问题。后来，通过多台云服务器分流，将每台云服务器的IIS并发连接降至2000以下，问题得到解决。
也许这只是某种特殊情况下的偶发问题，但问题持续了一个工作日，背后肯定有它潜在的原因。对于云平台这样复杂的、承载客户关键业务的系统，任何一个响应速度奇慢的问题都值得重视。虽然现在还没引起阿里云的足够重视，但是我们会继续研究。
与阿里云客服沟通下来，他们始终以“没有对IIS的并发连接进行限制”为理由，怀疑问题出在IIS。
而我们却有不同的想法：
1、同样的站点、同样的IIS设置之前在我们自己的服务器上运行多年，从没出现这样的问题。——直接证明IIS设置没问题
2、我们在IIS设置的最大并发连接数限制是5000，出现问题时，发连接数只有3500左右。——与IIS的并发连接数限制无关
3、3500的并发连接对IIS来说是小菜一碟，而且这里是静态文件，更加是小小菜。我们以前用自己的服务器，在单台服务器上不仅一个ASP.NET站点支撑2万并发连接没问题，而且这台服务器同时正常跑着同样的图片站点。——与IIS的处理能力无关
4、如果是IIS的原因，会有一个很直接的表现，通过性能监视器监测当前站点的当前连接数（Current Connections），会看到连接数不断增加。根据我们的观察，出现这个问题时，这个值在3500左右波动，并没有不断增加。——监测数据反映IIS在正常工作
根据我们的分析，我们没有找到一条可以把问题归罪于IIS的理由，再加上磁盘IO正常、带宽充足。如果只置身于云服务器中，你根本感觉不到有问题存在，一切都正常运转，世界很美好。
但是，这是一个虚拟的世界，支撑这个虚拟世界的背后是虚拟化平台。我们的猜想就从这个点出发。
当浏览器发出一个图片请求时，请求会先到达虚拟化平台，经过虚拟化平台到达云服务器的IIS，IIS收到这个正常的请求后作出正常的响应，将图片内容发向请求端，到这里一切都正常（可以通过云服务器的监测数据看出）。
但是，响应内容不是由云服务器的IIS直接发向浏览器，而是经由虚拟化平台处理。也就是在客户浏览器与云服务器的IIS之间横亘着虚拟化平台，如果云服务器中一切正常，客户浏览器得到的响应却极不正常，那会不会可能是虚拟化平台的某个处理环节出现问题了呢？。。。
这就是我们的猜想，也只能猜想。猜想也是一种对问题的思考，每个问题只要认真对待，总会有收获。
希望这只是一次特殊情况下的偶发现象，也希望阿里云能重视这个问题，排除可能的潜在原因。
- 海报
