swoole http server 效能優化

上線了乙個基於 swoole http server 的服務以後，發現這個服務的請求耗時監控毛刺十分嚴重，介面耗時波動比較大，經過一段時間的分析，發現這個服務 response 包十分大，有些 response 包高達1 ~ 2m，甚至更大，這樣就很清楚了，因為包太多，導致服務相應波動比較大。

這裡稍微解釋下，為什麼 response 包會導致相應時間波動，這裡主要有兩個方面的影響，第一是包大會導致 swoole 之間程序通訊更加耗時，並占用更多資源，第二是包大會導致 swoole 的 reactor 執行緒發包更加耗時，關於 reactor 的解釋，摘自

swoole的主程序是乙個多執行緒的程式。其中有一組很重要的執行緒，稱之為reactor執行緒。它就是真正處理tcp連線，收發資料的執行緒。 swoole的主線程在accept新的連線後，會將這個連線分配給乙個固定的reactor執行緒，並由這個執行緒負責監聽此socket。在socket可讀時讀取資料，並進行協議解析，將請求投遞到worker程序。在socket可寫時將資料傳送給tcp客戶端。

其實很簡單，那就是直接在 swoole 裡開啟 gzip，這裡摘自 swoole 文件

啟用http gzip壓縮。壓縮可以減小html內容的尺寸，有效節省網路頻寬，提高響應時間。必須在write/end傳送內容之前執行gzip，否則會丟擲錯誤。swoole_http_response->gzip(int le

vel=

1); lev

el=1

);level 壓縮等級，範圍是1-9，等級越高壓縮後的尺寸越小，但cpu消耗更多。預設為1，呼叫gzip方法後，底層會自動新增http編碼頭，php**中不應當再行設定相關http頭

使用php壓縮相應內容，然後使用 swoole_http_response->write 分段傳送，上線之後效果很明顯，耗時監控毛刺少了很多。

有些機智的同學或許會有這個疑問，swoole http server 一般情況下，會被 nginx 反向**，nginx 普遍會開啟 gzip，那麼問題來了，swoole 把資料 gzip 了，nginx 會不會把資料二次壓縮。

當然不會了，這可是nginx，來，雖然nginx的文件裡並沒有說明gzip不會被二次壓縮，但是我在原始碼裡找到了相關邏輯

src/http/modules/ngx_http_gzip_filter_module.c，略去無關**，下面函式呼叫ngx_http_gzip_ok檢測是否是gzip

src/http/ngx_http_core_module.c，略去無關**，ngx_http_gzip_ok根據http header檢測是否是gzip

從上述兩塊**可以看出，nginx 並不會對 gzip 的包二次壓縮。

所以，放心大膽的使用吧。

最後，雖然這篇文章，講的是針對swoole http server 做的乙個優化，但是這個思路，對於其他http server 也同樣適用。

FLASH ActionScript 效能優化

一.圖形方面的優化 1.減少同時在螢幕上物體的個數 2.儘量減少螢幕需要重畫的範圍。3.盡量避免全屏滾動 4.保持幀數在16 20,每一幀都連續，比將幀數設定的很高，但是每一幀的計算超過幀時間，讓人感覺更舒服。5.如果乙個物體不需要顯示，盡量將他從螢幕上刪除，而不是將他設定成不可見。因為即使不可見的...

Flink State Rescale效能優化

2017年社群有一篇部落格就比較深入的介紹了operator 和 keyed state的rescale的實現，感興趣的話可以去了解下。這兩張圖對比了是否基於keygroup來划區的乙個差別，社群中的版本使用的是基於keygroup的版本實現的，可以看到可以減少對於資料的random的訪問。但是從b...

調優 Nginx效能調優

一.nginx優化配置 1.主配置檔案優化 注 部分配置詳解 worker processes 8 nginx程序數，建議按照cpu數目來指定，一般為它的倍數。worker cpu affinity 00000001 00000010 00000100 00001000 00010000 00100...