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