簡介
記錄1次效能提升的經歷，它最大的挑戰不在於效能提升，而在於時間急，涉及的面廣（比如：機房F5的SSL/TLS效能，機房網際網路流量費和專案投入產出比等）。效能指標：至少支援10K QPS，10ms內服務應答，2+%的超時會被[流量方]（BATJ中的一家）打低業務流量，10+%的超時封號。
背景
因EA整體的架構規劃，部門A的試錯嚐鮮類需求被劃分給部門B來實現。這是1個網際網路引流的需求：[流量方]會將客戶移動端的加密裝置資訊呼叫我司介面，我司需告知[流量方]這個裝置是否需要看我司的廣告。9.20號部門B和[流量方]做了2次效能壓測，沒通過：1200 QPS，60+%超時率；800 QPS，17+% 超時率。本計劃9.22號上線，兼著部門A架構的我被安排進入專案。經多輪溝通分析，因該需求涉及的面比較廣，需向多位部門長、CTO彙報請示，同時要向集團IT報備，再加之8天的國慶假期，最後於10.13上線該需求。
兄弟部門B的失誤在於過於樂觀、簡單地看待了這個業務需求。通過了解生產環境現狀、多輪和[流量方]&集團IT溝通後，摸清了大體的情況
現狀分析
開始分析程式碼，以及整個鏈路的執行環境
解決方案
通過修改程式碼、變更Web容器提升單機效能，為後續橫向scaling做好基礎
效能壓測
下圖描述的主要是測試環境壓測的情況。可以看出，測試環境的壓測資料單機效能已經達到16+K 的QPS，但擔心[流量方]的統計指標（主要是併發數）有出入，因此預估生產環境叢集可以正常抗10K的QPS。在10.16日和[流量方]進行生產壓測後，發現叢集可以抗30K的QPS（這也是下圖【3倍生產環境[流量方]實壓轉換比】的參考來源）。其實還可以再往上壓，35K時[流量方]反饋響應耗時出現了波動，但網際網路的寬頻有限制，也擔心機房F5的問題，同時已超額滿足業務預期，就停止了生產的壓測
總結
部門B確實做過一些壓測，但測試目標不明確（眾多的效能指標中，應該以該需求最核心的Web伺服器響應耗時這個指標作為基線，來測試單臺機器支援的最大QPS），測試工具不準確（當時用部門B的壓測方法模擬1000 QPS，我查了下其實只有48的QPS），這也導致了上線前最後1關也就輕易的過了
另外，我也過於輕信了運維和安全同事他們對Openresty的壓測指標（可支援80+w的QPS），測試環境壓測時沒有測Openresty的效能。不過還好，安全的同事心虛了，在和[流量方]生產壓測前，當天下午生產環境壓測了一下Openresty的效能，緊急去掉了Openresty節點。當時Openresty壓測資料表明：在保證吞吐量的前提下，響應耗時只能是標準需求的介面延遲在200ms左右。關於Openresty的效能調優，或者是不是Openresty中的Lua指令碼有效能問題（理論上編譯型的Java會比解釋型的Lua快），這又是另1個話題了