這兩天閱讀《wireshark網路分析就這麼簡單》一書，作者在"patrick故事"一節中提到乙個問題分析的細節，於是決定記下：
有一台檔案伺服器的讀效能只有10mb/s，遠低於客戶的期望。我嘗試過很多調優方式，效能卻只降不公升。徒勞三天之後，我對自己徹底失去了信心。這時候我又想起了patrick，於是上傳了乙個網路包請他幫忙分析。一小時後收到了他的回信：
1. tcp超時重傳的間隔時間太長，設定乙個較小的時間可以減少重傳對效能的影響。
2. 該網路頻繁擁塞，擁塞點大多在32kb以上。如果把傳送視窗限制在32kb，就可以避免觸碰擁塞點。
這個案例中其實涉及以下幾個概念：
1. tcp慢啟動策略
2. tcp擁塞避免策略
3. tcp超時重傳策略
4. tcp快速重傳策略
5. tcp快速恢復策略
需要回答以下兩個問題：
1. 如何測量擁塞點？
2. 為什麼設定較少的重傳時間間隔可以減少對效能的影響？
要測量擁塞點，可以採用主次增加傳送量的方法，直到發生網路擁塞。但由於網路狀況可能存在一定不確定性，有時可能很堵，有時可能很空，因此擁塞點具有不確定性，也就是說，是動態變化的。
超時重傳，對傳輸效能存在嚴重影響。為了不給已經傳送擁塞的網路繼續添堵，一旦發生超時重傳，擁塞視窗將會自動降低到1個mss，並再次開始慢啟動過程。並且，這次從慢啟動過度到擁塞視窗的臨界視窗值，也就有參考依據了，《tcp/ip illustrated》將該臨界值定義為上次發生擁塞時的傳送視窗大小的一半。可見，擁塞視窗會因為擁塞發生而急劇減小，會降低接下去網路傳輸速度。
另外，超時重傳時間間隔（rto）如果設定過大，會導致超時等待的時間過長。
在google關於gfs的**，以及facebook關於mcroute設計的**中，均提到了針對tcp擁塞（incast）的處理策略。
《wireshark網路分析就這麼簡單》之「重傳的講究」一節，作者根據自身實踐，得出了以下結論：
1. 沒有擁塞，傳送視窗越大，效能越好。所以在頻寬沒有限制的條件下，應該盡量增大接收視窗，比如啟動scale option選項。
2. 如果經常發生擁塞，那限制傳送視窗反而能提高效能，因為即便萬分之一的重傳對效能影響都很大。
3. 超時重傳對效能影響最大，因為它有一段時間（rto）沒有傳輸任何資料，而且擁塞視窗會被設定成1個mss，所以要盡量避免超時重傳。
4. 快速重傳對效能影響小一些，因為它沒有等待時間，而且擁塞視窗減小幅度沒有那麼大。
5. sack和newreno有利於提高重傳效率，提高傳輸效能。
6. 丟包對極小檔案的影響比打檔案嚴重。因為讀寫乙個小檔案需要的包數很少，所以丟包時往往湊不滿3個dup ack，只能等待超時重傳。而大檔案有較大可能觸發快速重傳。
其他注意點：
1. 在使用wireshark抓包時，每個包的tcp層包含的window size實際是向對方宣告自己的接收視窗的大小。
2. 傳送視窗決定一口氣能傳送多少位元組，而mss（max segment size）決定這些位元組要分多少個包傳送。
3. tcp window scale，在tcp頭之外的option中，表示當前window size需要乘以多少倍。
關於MySQL效能調優
關於mysql處理百萬級以上的資料時如何提高其查詢速度的方法，有時候經常會忘記，所以在這裡做一些筆記，方便以後遇到問題的時候檢視。應盡量避免在 where 子句中使用 或 操作符，否則將引擎放棄使用索引而進行全表掃瞄 對查詢進行優化，應盡量避免全表掃瞄，首先應考慮在 where 及 order by...
關於效能調優
效能是指程式的處理效率無法達到預期值.導致效能問題的原因總的分為兩種,外部原因和內部原因.內部原因是指程式 本身有問題,無法高效地利用資源來完成計算.外部原因是指程式 以外的因素,比如硬體配置和程式的負載.解決效能問題的關鍵在於把瓶頸找出來,然後消滅瓶頸.預備 為了防止進入永無止境的效能優化圈 客戶...
調優 Nginx效能調優
一.nginx優化配置 1.主配置檔案優化 注 部分配置詳解 worker processes 8 nginx程序數，建議按照cpu數目來指定，一般為它的倍數。worker cpu affinity 00000001 00000010 00000100 00001000 00010000 00100...