人名控制項的效能優化的解決思路：
1.前端js
2.資料的網路傳輸
3.後台邏輯
4.資料庫
/**********************前端js***********************************/
前端js基本上沒有過多的優化餘地。如果要修改獲取資料的方式為分段取，那麼改動將比較大，暫時不做
/**********************網路***********************************/
這塊是大頭。整個公司的人名拼起來的字串有378k,那麼網路傳輸的耗時將非常可觀。檢查發現apache沒有開壓縮
簡單地將deflate開啟，將人名資料壓縮到110k。使用預設的壓縮等級為6。這樣網路傳輸的時間降為100ms以內
但是當請求郵件組時，這個字串達到了579k（天啊好大），壓縮後為156k。但是測試發現居然還是要接近1s的時候來傳輸。
跟前面的110k的網路時間完成不成比例，懷疑156k超過了apache的網路緩衝區的臨界值吧。這個問題後面再繼續研究。
同時，經過實驗，不斷地調整壓縮等級也可能帶來一定的提公升，經過幾次試驗後，我發現在開發機上壓縮等級為2可以使用網路傳輸最快。
/**********************後台邏輯***********************************/
由於cake框架的制約可能這個簡單的請求會多餘很多的邏輯。所以想把它剝離出來，用祼php來寫。
寫了個hello world測試了一下發現單個請求大約只提公升了70ms+吧，空間不大，可能是人名請求沒有載入多過的model吧。
暫時放棄剝離。
檢查邏輯發現使用cake的model來查詢資料庫可能也走了很多不必要的邏輯，因為將其改為直接連線資料庫並使用sql直接查詢，
這樣帶來了100ms-200ms+的提公升。
/**********************資料庫***********************************/
檢查資料庫發現人名資料的表沒有對enabled欄位建立索引，因此將其加上。發現並沒有帶來效能上的提公升。因為enabled的值是0和1，
且我們都是查詢1的資料，這樣的資料幾乎佔了全部資料的80%，因此這個所以幾乎無效。
真正導致人名資料查詢效能低的原因是取出來的資料太多了。於是嘗試用sql來把人名拼起來，查義時只返回乙個字串即可。
於是用group_concat和concat將結果進行拼裝，發現更慢了。。分析發現，其實資料庫做字串操作要比php慢多了。。
為了解決從磁碟取過多資料的問題，於是使用了mysql的記憶體表，這樣資料將存在於記憶體中，減少了io的查詢，具體可以提公升多少效能
還需放到正式資料庫上進行測試，因為俺們的開發資料庫只有可憐的2g記憶體。。一直處理滿狀態，建了記憶體表只會更慢，因為記憶體不夠用
導致了虛擬記憶體的使用。
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...