客户端比较
Netty 4.0.8（无连接池）
Apache HttpAsyncClient 4.0-beta4（启动连接池）
Apache HttpClient 4.3（启用连接池）
测试设置
在服务器端，在Amazon EC2云中设置了一组服务器。它们都服务相对静态的内容，其中唯一的变化是可以从客户端的查询参数控制的有效载荷的大小。每个服务器运行300个线程的Tomcat应用程序。
客户端在我的笔记本电脑上运行，这是一个Macbook Pro（2.4Ghz英特尔酷睿i7）运行JVM 1.6.0_51 2G字节堆大小。测试不同的请求批量大小。每个批处理在一个循环中发送所有请求，并运行多次而不关闭JVM。一个批次大小的测试结果是所有运行的平均值。来自批处理的第一次运行的数据被忽略，因为它通常包括JVM，线程池和连接热身。
指标
从测试收集或计算三个指标
·发送所有请求所需的时间。对于基于线程池的阻止客户端，请求被认为是当它从线程池出队并且交接给客户端时发送。对于Netty，当获得ChannelFuture时，请求被认为是发送的。对于Apache HttpAsyncClient，当Future＆lt; HttpResposne＆gt;时，请求被认为是发送的。对象。
·平均延迟。对于NIO客户端，当请求切换到客户端时，定时器启动。对于HttpClient，当请求入队到线程池时，定时器启动。当接收到完整的HTTP响应时，定时器停止。对所有请求累积该时间，并用于计算平均值。
·吞吐量。这只是批处理的大小除以发送时间。
结果
有趣的是，观察到最好的延迟是通过具有合理大小的线程池的阻塞I / O客户端实现的。这可能是因为每个套接字在阻塞I / O中都有一个专用线程，而在NIO中，只有少数选择器需要轮询数百甚至数千或套接字。另一方面，当线程池的大小增加时，等待时间变得更糟。
与Netty相比，HttpAsyncClient具有更好的延迟，因为它具有内置的连接池支持。
结论
我相信NIO客户端的性能优势是在吞吐量方面。如果您的服务要求客户端吞吐量超过1000 rps，请考虑使用NIO客户端以避免瓶颈。另一方面，如果服务只需要几百rps，使用具有合理大小的线程池的阻塞HttpClient是可管理的，并且将获得更好的延迟。
HttpAsyncClient享受内置连接池的好处。当客户端必须处理数千个并发请求时，这被证明是至关重要的。但是，请注意，这只是HTTP客户端与相对简单的用例的比较，Netty显然有更广泛的协议支持。
原文地址：http://allenxwang.blogspot.com/
版权声明：本文来源CSDN，感谢博主原创文章，遵循 CC 4.0 by-sa 版权协议，转载请附上原文出处链接和本声明。
原文链接：https://blog.csdn.net/maoyeqiu/article/details/58595099
站方申明：本站部分内容来自社区用户分享，若涉及侵权，请联系站方删除。
