多线程-网络请求线程数设置

自己闲暇时，也曾尝试实现过简单的线程池，对高并发有过预生产的压测和调优，然而一直我都是作为服务提供方在做多线程。

 

最近，接过一个服务消费方的代码，看过代码，实现上并没有看出问题，每秒也有过千的请求并发效果，但是领导要求完成每秒两万。

凭借我一直的实践和阅读，理论上 线程数 = 2*CPU数时，可以达到一个最优的性能表现。

当下机器配置 12台 8C 机器，理论每台 16线程相对不错了。

按服务方说明，http请求，响应延时 10ms

计算理论值 200ms(tcp握手+延时) ，每秒每个线程可以 5次请求。

 

问题来了，16线程见鬼去吧。

 

猜测，16线程的理论值应该是非网络环境或者长连接情况下的一个结果。

16线程的最优是考虑了线程调度的花费，而在tcp握手面前，这个调度几乎应该忽略，重新计算线程数，20000  / 12 / 5 > 333

理论上是这样的，情况可能会比我想象的要好一些吧！

 

实际生产将会发生什么，是我一直都不敢给领导保证的，实际结果还是在千级徘徊。

猜测是，服务方的说明和实际性能不符。

本想和代码作者分析个可能的原因，然而接手的锅还是得自己动手，添加日志。

一路日志重新请求，日志显示，实际服务方的响应延时在10ms-10s不等，且多数响应实际为4s。

永远不要完全相信服务方的承诺，尤其国内，我的脑子里冒出这个曾经的经验。

 

线程数干到千级不多说，虽然仍未达到预期，但也已能够解释原因和完成基本场景要求。

准备收拾下班，愿明天 不再如此泥泞。

 

补充：

  考虑到国内运营商间网络的通信延时，可能服务方并没有谎报他们的响应延时（他们服务器的处理时间10ms）。

至于中间是否存在更多中转可能都会对网络请求响应贡献时间。

转载于:https://www.cnblogs.com/qq1144054302/p/10381318.html