集羣服務器使用nginx+fpm（php）的結構，這種結構的性能很大程度的瓶頸在fpm這一層，隨着業務發展，訪問量的增加，爲了保證用戶體驗，我們在通過各種手段去提升集羣的吞吐量和服務質量——機器擴容、業務分池、MC/REDIS的local化等等，做下來看到的效果是明顯的，不過量級上的提升還是迫切需要，於是想到了在web服務器上在下下功夫，集羣使用的nginx版本有點歷史，版本就不說了，不過一直跑的都很健壯，所以沒從想過更換，在負責之前業務時使用tengine，性能表現良好，於是果斷測試升級，沒想到升級改造後性能是質的提升，30ms以內的響應從原先的20%提高到了80%，100ms以內的響應從原來的70%提高到了90%，升級過程不說了，看看升級前後的數據比較吧，數據均是生產環境實際監控：
活躍連接數監控如下：
從下午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服務器。
請求相應時間曲線圖比較（綠色是30ms以內請求，拐點爲升級點）：
最後再上張餅圖形象的比一下（綠色爲30ms以內，紅色爲500ms以上）：
自建個人原創站運維網咖社(www.net-add.com)，新的博文會在網咖社更新，歡迎瀏覽。