公司有一个Web Service，访问量不大， 但也不算小， 每天几百万的量级。正常情况下， 平均每个请求响应的时间在200毫秒左右。
每天几百万的访问量， 那么程序每秒请求处理数量在几十个左右， 高峰期也就上百， 而服务器上php处理请求的进程数是大于这个数的，因此， 服务器的处理能力勉强能满足当前量级的请求， 除了少数时候高峰期会出现不稳定的状况， 大多数时候也算是相安无事， 但是从服务器失败请求的数量来看应该离服务器处理能力极限的临界点不远了。
这个Web Service有一个特点， 它并不是面向终端的 ， 而是为另一套Web Service提供底层数据用， 那套Web Service会进行数据缓存，不会把所有数据请求转发到我们这里，它替我们挡掉了大部份压力。然而， 天有不测风云，某一天高峰期那套Web Service的缓存机制坏掉了， 所有数据请求全都转发到我们的Web Service上， 结果， 我们Web Service访问量成倍增长，服务器超出了承受能力的范围而无法正常响应，然后用户各种投诉，领导各种不满，压力自然而然就到了我的身上。
我分析了一下问题的原因，Web Service 每个请求的响应时间为200毫秒上下， 服务器的并发处理能力并不是很高， 也就是说在每个200毫秒内，服务器处理请求数量是有极限的， 当每200毫秒的请求量大于这个极限的时候， 后面进来的请求就不能被及时处理， 只能排队等待，这就跟堵车一下，车的数量远大于马路的吞吐量时，自然是越堵越多。堵车没有时间限制， 反正迟早能开走， 只是花点时间等待而已。 而服务器处理请求就不一样了，如果指定的时间范围内无法及时处理请求，那么这些请求就会坏掉， 也就是我们通常看到的502或者504。我们的服务器也是因为这个原因而出现了大量的坏掉的请求，导致业务受到影响。
