爲什麼談HTTP1.1 Pipelining呢？主要問題根源還是來源於Beetlex參加了techempower的測試。先看一下以下兩項測試的結果：
以上分別是.net平臺的Json和Plaintext的測試結果，其實Plaintext最高能跑700多萬RPS已經完全超了對網絡IO讀寫損耗的認知，即使10G的光卡也不可能每秒承載1400萬的IO R/W。Beetlex在其他測試結果都非常不錯，但在最基礎的Plaintext得到了最差的結果！爲了解決這一問題我看了N次aspcore的框架代碼看有沒有細小的差異引起問題，結果經過N次的嘗試一年後還是無法解決。。。
發現問題
最近我翻看了techempower針對20輪的測試說明，其中有一條說是要廢棄Plaintext項，說這一個項並不符合實際應用需求。後來看了一下評論的一項
在這裏我纔看到了HTTP/1.1的pipelining描述。。。後來查了一下資源才發現techempower好像在2015年單獨爲Plaintext測試項引入pipelining模式，主要用於測試框架在帶寬上的吐吞能力，而beetlex在實現HTTP1.1裏並沒去實現它！看到這信息後心裏瞬間無數的草尼馬飄過。。。
Pipelining模式有什麼好？
在這裏先說一下HTTP/1.1的基礎通訊模式，就是發起一個請求後等待響應後再發起下一個請求；這樣每個請求響應最少佔用一個網絡讀和網絡寫的操作。在pipelining模式下的操作則是可以同時發起多個請求，然後等待多請求同時響應，這就意味着多請求響應可以合併到一個網絡讀寫上，這樣的性能提供是巨大的.由於pipelining模式的使用是非常有限，只允許GET和HEAD請求，所以很多語言的HttpClient組件並不支持這種方式。
從上圖可以瞭解到，非pipelining模式下，三個請求最少佔用3次IO讀寫，而使用pipelining後則可以縮減成1次IO讀寫,這樣有多少性能提升可以查看《評估服務基礎性能應該參考那些指標？》。對http1.1的pipelining瞭解 發現techempower的Plaintext測試之所以有這麼高的響應能力並不是爲了反映服務器的網絡IO高效，而是通過pipelining模式實現的一個高帶寬吞吐的技巧測試，由於不具備實用性所以纔在討論中提議廢棄它。
總結
由於沒有了解techempower的細節導致一直踩在這坑上，整整浪費了大量的時間去查看實現問題；由於姿勢不對未能解決問題，但在調整過程中也嘗試各種線程隊列調整和測試收穫還是有的，更重要的一點是BeetleX不再爲這一問題而煩惱。