問題：
使用了brpc的長連線，但是為何耗時和短鏈結一樣呢？
brpc文件裡介紹，使用http協議，則預設使用pooled，只要連線數不超過max_connection_pool_size，則都可以使用長連線。
但是在實際使用中，發現整個請求耗時很長，使用curl結果如下：
curl -s -w %"\r\n"%"\r\n"%"\r\n"%"\r\n"%"\r\n" -d ""
time_namelookup : 0.000
time_connect : 0.033 tcp建立連線耗時.
time_pretransfer : 0.033 tcp連線建立完成後，客戶端開始傳遞第乙個位元組的時間
time_starttransfer : 0.070 服務端響應開始傳輸第乙個位元組的時間 (雖然很多資料上說是服務端響應第乙個位元組的時間，但是根據我多次試驗資料我更認為是：客戶端收到服務端響應的第乙個位元組的時間)
time_total : 0.070 整個請求到響應完成的耗時
由此看出：
tcp建立連線，三次握手，耗時1.5rtt，耗時33ms；
資料傳輸：70-33=37ms，也就是客戶端把資料傳給服務端(0.5rtt) + 服務端處理(對方說5ms) +服務端把資料傳回客戶端(0.5rtt) = 37ms；也就是說1rtt = 32ms.
誤區：開始一直認為服務端內部有32ms(37-5)不知道哪去了，但是沒想到的是我竟然把資料傳輸的1rtt給忽略了。
因為建立連線需要33ms，傳輸資料也需要32ms，服務端資料處理需要5ms，如果每次請求建立成功了長連線，則就可以省去tcp建聯的33ms，也就是整個請求是37ms，符合預期。
結論：從線上統計請求好時看，平均耗時70ms，所以可以確定長連線沒建立成功。
解決：既然brpc介紹用pooled連線池是長連線，那會不會是連線超過max_connection_pool_size了，所以很多都是短連線？ 於是調得更長，也不行。
netstat -ant|awk ''|sort|uniq -c 分析：
61 close_wait
1 established)
2212 established
1 fin_wait2
19 listen
1 state
2016 time_wait
time_wait有2016個，說明有很多連線主動關閉，也就意味著請求是短鏈結，頻繁連線關閉，那麼可以確定，儘管使用了pooled，依然是端連線。
繼續分析：發現有個defer_close_second引數，表示連線是立即關閉還是延遲多少秒後關閉。將該引數值從0改為120後，請求耗時從70ms降低到35ms了。
也是奇怪，既然pooled用長連線了，為何還要用defer_close_second來把問題複雜化？
brpc原始碼 server類
brpc master src brpc server.cpp server類的啟動涉及有以下幾個方法的呼叫 addservice start rununtilaskedtoquit 的幾個addservice 基本都是再呼叫addserviceinternal 方法 這個方法主要實現了 關於pro...
brpc第一周學習分享
由於自己第一次讀開源 所以完全沒有方法，所以第一步是瘋狂google brpc學習最佳實踐 如何閱讀源 最終找到一篇比較好的文章 如何閱讀乙份源 目前自己的大計畫是一年能夠改寫brpc 所以小計畫是當前乙個月先搞清楚brpc的基本框架，了解基本結構 制定以上計畫的原因如下 閱讀技巧 然後跟著brpc...
隨機訪問 順序訪問
讓隨機變成順序 技術思想 訪問結構 分為隨機訪問和非隨機訪問 又稱順序訪問 1 隨機訪問就是直接訪問，可以通過下標直接訪問的那種資料結構，與儲存位置無關，例如陣列。非隨機訪問 就是順序訪問了，不能通過下標訪問了，只能按照儲存順序訪問，與儲存位置有關，例如鍊錶。2 順序訪問就是訪問第n個資料時，必須先...