集群服务器使用nginx+fpm（php）的结构，这种结构的性能很大程度的瓶颈在fpm这一层，随着业务发展，访问量的增加，为了保证用户体验，我们在通过各种手段去提升集群的吞吐量和服务质量——机器扩容、业务分池、MC/REDIS的local化等等，做下来看到的效果是明显的，不过量级上的提升还是迫切需要，于是想到了在web服务器上在下下功夫，集群使用的nginx版本有点历史，版本就不说了，不过一直跑的都很健壮，所以没从想过更换，一个简单的事情促使我想测试更换为tengine，那就是worker进程数的设置。我们的服务器集群分布在各地，配置文件是puppet统一下发，服务器的cpu核心数有8、12核的，nginx只支持worker进程数写数量，当前线上设置的是12，也就是说8核心的cpu起12个工作进程，凡是用nginx的都知道，这样会出现一些莫名其妙的错误，而tengine是可以支持auto的写法，这样根据cpu的核心数自动启动对应数量的worker进程，误打误撞，没想到升级改造后性能是量的提升，过程不说了，看看升级前后的数据比较吧，数据均是生产环境实际监控：
活跃连接数监控如下：
从下午3点做的升级改造，在同等环境只升级改造了web服务器的条件下（QPS大概在300到500之间），web的活跃连接数降为了原来的三分之一并保持稳定，大家都知道，如果同样数量的请求，处理的越快nginx的活跃连接数就会越少，处理的慢了才会对活跃连接数以及tcp进行堆积，推测性能是有很好的提升的，但这个数据还不能说明问题，因为最终要看用户的访问质量，继续查数据分析。
日志的响应时间对比如下（1个小时）：
注：时间是区间，第一个是小于10ms，第二个是大于10小于30ms，第三个大于30小于50ms依次类推...
从图表可以清楚的看出升级前后的相应时间对比，如果以30ms和100ms为两个槛做比较（500ms以上我们就算超时了），得出30ms以内的响应请求从原来的20%提升到了80%，如果计算100ms以内的请求是从原来的68%升到了92%，相比1s以上的长相应请求从原来的3.9%降到了不到1%的量，可以说是效果非常明显，性能提升数倍，tengine在某些方面不愧是一款利器，当然升级过程中也遇到了一些配置上的小曲折，总之业务性能优化永无止境,tengine不愧是一款优秀的和fpm搭配的web服务器。
最后再上张图形象的比一下：
