为什么谈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不再为这一问题而烦恼。
