AbstractBatchDecoder 批量解码器在高并发下可能存在bug

[lexburner]

我使用dubbo做了一个简易的rpc测试，使用AbstractBatchDecoder代替ByteToMessageDecoder之后，在handler中判断List还是单个response。经过高并发的压测，发现始终有个别请求会响应失败，异常未知；地并发下很稳定。官方是否有提供过压测脚本，AbstractBatchDecoder到底能提升多少qps？以及是否存在响应失败的问题

[khotyn]

请 @xmtsui 帮忙回答一下。

[xmtsui]

1. 请求失败的问题，目前我们线上是这样在用的，没有碰到过这样的问题，不知道是否方便贴一下代码，我也来看下你的实现，分析下是不是我们有什么定制或者抽象不好的地方，导致你们直接使用有问题。
2. 性能这块当时压测的数据我找不到了，在高并发下的优化很明显（印象有20%以上），低并发不明显，不过没有未知异常的失败情况。我回头整理下bolt-benchmark，也把压测工程开出来，到时也把具体数据提供出来。

@lexburner

[xmtsui]

内部做了一些压测，当前结论是

对于bolt在Epoll和Decoder上的优化性能，测试的反馈如下：
在Epoll方面，Epoll带来的性能提升比较明显，整体在10%左右，不论是消息还是rpc调用上都有优秀的发挥，消息收发上来说对于高连接数的高并发的场景，性能会提高至10%以上,在低连接数时的性能提升较低；在RPC调用这块，Epoll的提升比较全面，低连接数时的性能在6%~8%左右，在高连接数时能达到10%。
在Decoder方面，AbstractBatchDecoder和ByteToMessageDecoder在低并发的情况下，不论是消息还是rpc调用两者的性能相当。但是AbstractBatchDecoder相比ByteToMessageDecoder来说，其批量处理的特性使得它在
高并发的情况下能够获得显著的性能提升，经过反复测试，在10%以上，且请求的大小越小性能提升越大。
在两者都开启的情况下进行测试，可以发现整体性能有着显著的提升，在消息收发方面，平均提升在10%左右，最高可达20%，与消息的大小成反比；在RPC调用方面，整体的提升可达20%以上，与并发数连接数的增加成正比，最高可达33%。

测试工程准备ok后再开放，本issue先关闭了