????????為什么談HTTP1.1 Pipelining呢？主要問題根源還是來源于Beetlex參加了techempower的測(cè)試。先看一下以下兩項(xiàng)測(cè)試的結(jié)果：

以上分別是.net平臺(tái)的Json和Plaintext的測(cè)試結(jié)果，其實(shí)Plaintext最高能跑700多萬(wàn)RPS已經(jīng)完全超了對(duì)網(wǎng)絡(luò)IO讀寫損耗的認(rèn)知，即使10G的光卡也不可能每秒承載1400萬(wàn)的IO R/W。Beetlex在其他測(cè)試結(jié)果都非常不錯(cuò)，但在最基礎(chǔ)的Plaintext得到了最差的結(jié)果！為了解決這一問題我看了N次aspcore的框架代碼看有沒有細(xì)小的差異引起問題，結(jié)果經(jīng)過N次的嘗試一年后還是無(wú)法解決。。。

發(fā)現(xiàn)問題

????????最近我翻看了techempower針對(duì)20輪的測(cè)試說明，其中有一條說是要廢棄Plaintext項(xiàng)，說這一個(gè)項(xiàng)并不符合實(shí)際應(yīng)用需求。后來看了一下評(píng)論的一項(xiàng)

在這里我才看到了HTTP/1.1的pipelining描述。。。后來查了一下資源才發(fā)現(xiàn)techempower好像在2015年單獨(dú)為Plaintext測(cè)試項(xiàng)引入pipelining模式，主要用于測(cè)試框架在帶寬上的吐吞能力，而beetlex在實(shí)現(xiàn)HTTP1.1里并沒去實(shí)現(xiàn)它！看到這信息后心里瞬間無(wú)數(shù)的草尼馬飄過。。。，原因這一年針對(duì)這一問題的解決方法完全是姿勢(shì)不對(duì)！

Pipelining模式有什么好？

????????在這里先說一下HTTP/1.1的基礎(chǔ)通訊模式，就是發(fā)起一個(gè)請(qǐng)求后等待響應(yīng)后再發(fā)起下一個(gè)請(qǐng)求；這樣每個(gè)請(qǐng)求響應(yīng)最少占用一個(gè)網(wǎng)絡(luò)讀和網(wǎng)絡(luò)寫的操作。在pipelining模式下的操作則是可以同時(shí)發(fā)起多個(gè)請(qǐng)求，然后等待多請(qǐng)求同時(shí)響應(yīng)，這就意味著多請(qǐng)求響應(yīng)可以合并到一個(gè)網(wǎng)絡(luò)讀寫上，這樣的性能提供是巨大的.由于pipelining模式的使用是非常有限，只允許GET和HEAD請(qǐng)求，所以很多語(yǔ)言的HttpClient組件并不支持這種方式。

從上圖可以了解到，非pipelining模式下，三個(gè)請(qǐng)求最少占用3次IO讀寫，而使用pipelining后則可以縮減成1次IO讀寫,這樣有多少性能提升可以查看《評(píng)估服務(wù)基礎(chǔ)性能應(yīng)該參考那些指標(biāo)？》。對(duì)http1.1的pipelining了解 發(fā)現(xiàn)techempower的Plaintext測(cè)試之所以有這么高的響應(yīng)能力并不是為了反映服務(wù)器的網(wǎng)絡(luò)IO高效，而是通過pipelining模式實(shí)現(xiàn)的一個(gè)高帶寬吞吐的技巧測(cè)試，由于不具備實(shí)用性所以才在討論中提議廢棄它。

總結(jié)

????????由于沒有了解techempower的細(xì)節(jié)導(dǎo)致一直踩在這坑上，整整浪費(fèi)了大量的時(shí)間去查看實(shí)現(xiàn)問題；由于姿勢(shì)不對(duì)未能解決問題，但在調(diào)整過程中也嘗試各種線程隊(duì)列調(diào)整和測(cè)試收獲還是有的，更重要的一點(diǎn)是BeetleX不再為這一問題而煩惱。

總結(jié)

以上是生活随笔為你收集整理的了解一下HTTP1.1 Pipelining技术的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。