8月份升級之後用戶普遍反映系統變慢，然後就開始了性能優化之路。
一、升級之後出現兩個問題：
1、加載城市列表時出現空白頁，黑科技接口導致，加載城市列表的接口過於簡單粗暴，調用app端接口時將所有商戶的所有繳費項目，拼接上商戶地址信息，返傳給web端服務器，三張表中的數據雜糅在一起，數據量大，遍歷多張數據表操作開銷大，導致在web端調用app端接口時curl原先設置的3秒超時時間不夠用，接口調用失敗。
解決方式：分拆接口，將該接口拆成若干個接口，去掉無用數據，保證跨服務器傳輸數據的效率，並在接口中加上memcache緩存，減少查詢數據庫次數。
2、首頁相應十分遲緩，打開首頁需要十秒左右，原因：
1，郵儲APP退出之後，會清除緩存，導致用戶每一次重新打開APP就需要完全加載項目資源。
2，首頁靜態資源太大，由於靜態資源全封裝在header文件中，引用後會加載全部資源。
3，生產服務器Apache未開啓gzip文件壓縮
解決方式：打開Apache的gzip壓縮，首頁不引用header文件，只在頁面中引用必須的靜態資源，壓縮jQuery等靜態文件，首頁菜單由查庫操作改爲配置文件。成效顯著，首頁加載數據大小由原先800K降低至80K左右，首頁響應速度提升明顯。
二、邏輯優化
使用xhprof性能分析工具測試用戶端邏輯，找出內存或CPU消耗較大的代碼，項目中有一些老的已經沒有使用場景的方法依然在運行着，消耗系統資源，去掉，項目中查庫頻繁的操作使用memcache緩存，減少查庫次數。
三、壓力測試
聯繫了郵儲相關部門對項目進行壓力測試，測試內容包括單一功能點壓測、單獨首頁壓測、用戶端整體流程壓測、兩輪壓測
第一輪壓測：總體，30併發，tps:58筆/s, 171前端機CPU佔用80%，173後端機無壓力，數據庫服務器無壓力，memcache服務器無壓力
單一首頁壓測，tps:450筆/s，171前端機CPU佔用100%
第二輪壓測：
1，恢復首頁優化之前的代碼，壓測單一首頁，tps:110筆/s，總體40筆/s，平均時間0.139s
2，恢復首頁優化之前的代碼，開啓gzip，單一首頁：tps140筆/s，相應時間0.157s，CPU佔用30%,CPU使用率不再上漲
3，開啓gzip，使用優化後的首頁代碼，壓測單一首頁，tps:576筆/s，響應時間0.026s，171前端機CPU70%，佔用率不再上漲
整體壓測，壓力全在前端機，數據庫服務器，app服務器，memcache服務器均無太大壓力