当用路过秋天的压力测试工具重现问题的那一刻，热泪盈眶！这段时间所承受的一切一涌而出。。。
下面这张图是首次压力测试重现问题时的Windows性能监视器截图，我们对这样的图太熟悉了，当它一出现，就知道问题重现了。红色的直线表示的是100%的CPU占用率，蓝色如栅栏的线条是ASP.NET请求执行时间（Request Execution Time）。这时如果用浏览器访问站点，会奇慢无比。
我们是这样进行压力测试的，将一台Web服务器从阿里云SLB（负载均衡）中摘下来，其他运行环境（Web程序、Memcached、NoSQL、RDS）没有任何变化，然后用压力测试直接向这台Web服务发出请求。压力测试工具造成这台云服务器的TCPv4->Connections Established（性能监视器的一个监测指标）超过2000，问题立即重现。
TCPv4->Connections Established这个指标在我们之前的博文中从没提过，而它就是今天取得突破的关键所在。简单来说，它表示的是这台服务器的当前TCP连接负载。今天下午我们发现，正常期间Connections Established的数值都在1000以内，而故障期间这个值都会超过1000。在出现故障的时候，只要我们以某种方式将Connections Established的数值降到1000以下，故障就会消失，比如重启IIS、禁用网卡，甚至重启Memached/NoSQL服务器（它们与Web服务器之间进行频繁的TCP连接）也能解决问题。
我们的压力测试就是针对TCPv4->Connections Established，只要压到1000以上，问题就会重现；降到1000以下，问题就会消失。（另一张压测截图）
为了进一步验证是这台云服务器本身的问题，与周边环境无关。在压测时这台云服务器CPU 100%、访问奇慢无比期间，我们访问处于同样环境的其他云服务器，速度飞快。
根据压测情况，我们的猜测是：在某种特定的条件下，当云服务器（Xen虚拟机）的并发TCP连接数超过一定的数值（目前我们的估计是1000~2000），云服务器的CPU占用率会飙升或大幅波动，某些处理能力会急剧下降，比如ASP.NET的请求处理时间由“几十毫秒”狂飚至“几十秒”。（仅是我们单方面的猜测，并不代表阿里云云服务器的真实情况）
那我们是如何找到TCPv4->Connections Established的呢？
这要从今天凌晨4点多路过秋天对我们的站点进行短暂的压测说起。压测之后，我们发现不仅4台8核的Web服务器的CPU没撑住，竟然连8核的Memcached服务器的CPU也没撑住。这说明问题与应用程序没有关系，如果是应用程序的原因，那不应该出现Memcached服务器CPU撑不住的情况。应用程序与Memcached软件（Couchbase）都会引起这个问题的可能性估计一万看才会遇到一次。所以从这个压测，我们进一步排除ASP.NET应用程序引起这个问题的可能性。
今天上午故障期间，我们特地禁用Memcached/NoSQL进行观察，问题仍旧。进一步排除了Memcached/NoSQL引起这个问题的可能性。问题与虚拟机的CPU占用高有关，这是板上钉钉的事实，但是究竟什么触发了CPU占用高比这个事实更重要。CPU不会喝酒喝多了，不会发羊癫疯。。。肯定是某个因素造成的。
IIS并发连接数是一个嫌疑对象，但很难确定是因为CPU占用高造成IIS并发连接数上升，还是因为IIS并发连接数上升造成CPU占用高。在下午的故障期间，我们发现重启Memcached/NoSQL竟然也能解决问题，说明问题即使与IIS并发连接数有关，但也不是仅与IIS并发连接数有关。
后来，我们在网上找到了一些说Xen虚拟机TCP处理能力可能存在问题的线索（这只是启发我们思考问题的线索，不代表现在的Xen虚拟机还存在这个问题）。于是，我们把虚拟机的TCP处理能力作为一个怀疑对象，并在Windows性能监视器中找到一个监测指标——TCPv4->Connections Established，在下午故障期间特地监测了这个指标，才发现前面所说的Connections Established在1000以下一切正常，1000以上就出故障。然后在压力测试中专门针对这项指标进行测试，才重现了问题。
那如何解决这个问题？
从我们自身角度，我们会想办法尽量减少单台云服务器的TCPv4->Connections Established，究竟什么办法是有效的，需要经过明天访问高峰期的验证。
。。。
热泪盈眶的不仅仅是因为在煎熬中看到了曙光，更是因为给大家带来这么多这么大的麻烦，总算有了一点交代。
彻底解决这个问题后，我们会以更好的产品、更好的服务去弥补！
