标签：0ms 并发 下机 简单的 添加 cpu 动手 连接 线程调度
自己闲暇时，也曾尝试实现过简单的线程池，对高并发有过预生产的压测和调优，然而一直我都是作为服务提供方在做多线程。
最近，接过一个服务消费方的代码，看过代码，实现上并没有看出问题，每秒也有过千的请求并发效果，但是领导要求完成每秒两万。
凭借我一直的实践和阅读，理论上 线程数 = 2*CPU数时，可以达到一个最优的性能表现。
当下机器配置 12台 8C 机器，理论每台 16线程相对不错了。
按服务方说明，http请求，响应延时 10ms
计算理论值 200ms(tcp握手+延时) ，每秒每个线程可以 5次请求。
问题来了，16线程见鬼去吧。
猜测，16线程的理论值应该是非网络环境或者长连接情况下的一个结果。
16线程的最优是考虑了线程调度的花费，而在tcp握手面前，这个调度几乎应该忽略，重新计算线程数，20000 / 12 / 5 > 333
理论上是这样的，情况可能会比我想象的要好一些吧！
实际生产将会发生什么，是我一直都不敢给领导保证的，实际结果还是在千级徘徊。
猜测是，服务方的说明和实际性能不符。
本想和代码作者分析个可能的原因，然而接手的锅还是得自己动手，添加日志。
一路日志重新请求，日志显示，实际服务方的响应延时在10ms-10s不等，且多数响应实际为4s。
永远不要完全相信服务方的承诺，尤其国内，我的脑子里冒出这个曾经的经验。
线程数干到千级不多说，虽然仍未达到预期，但也已能够解释原因和完成基本场景要求。
准备收拾下班，愿明天 不再如此泥泞。
标签：0ms 并发 下机 简单的 添加 cpu 动手 连接 线程调度
原文地址：https://www.cnblogs.com/qq1144054302/p/10381318.html
