每秒处理请求数和并发的关系

设平均响应时间为t(单位为毫秒), 并发量为c,每秒处理请求数为q,则: 
q = (1000/t) * c 
就是这个关系; 
想要升高q,就只有两条路:1) 降低t 2) 升高c 
对于'1', 只能靠优化代码实现,只能尽量做,往往提升有限; 
对于'2', 通常c与你服务器程序的请求处理模型有关,如果你服务器程序是“一个线程对应一个请求”的模式,那么c的最大值就受制于你能支撑多少个线程;如果是“一个进程对应一个请求”的模式,那么c的最大值则受制于最大进程数;

在升高c的过程中,不得不注意的一点是,线程/进程数越多,上下文切换、线程/进程调度开销会增大,这会显著间接地增大t的值从而不能让q跟着c的值等比升高, 所以一味增大c通常也不会有好结果,最合适的c值应该根据实测试验得出

另外,还有一种特殊情况:若业务决定了该服务器提供的服务具有“小数据量、较长返回时间”的特征,即这是一个不忙、但很慢的业务类型,那么可以采用NIO模式提供服务,比如nginx默认就采用nio模式; 
在这种模式下,c值不再与线程/进程数相关,而仅仅与“socket连接数”相关,通常“socket连接数”可以非常大,在经过特殊配置的linux服务器上,可以同时支撑百万级别的socket连接数,在这种情况下c可以达到100w; 
在如此高的c值之下,就算t再大,也可以支撑出一个很高的q,同时真正的线程/进程数可以只开到跟cpu核数一致,以求最大化cpu利用率; 
当然这一切的前提是该业务具有“小数据量、较长返回时间”的特征

 

并发量是当前保持的连接数

 netstat -ntp | grep -i "6661" | wc -l
(No info could be read for "-p": geteuid()=512 but you should be root.)
89

posted @   lclc  阅读(1536)  评论(0编辑  收藏  举报
编辑推荐:
· AI与.NET技术实操系列(二):开始使用ML.NET
· 记一次.NET内存居高不下排查解决与启示
· 探究高空视频全景AR技术的实现原理
· 理解Rust引用及其生命周期标识(上)
· 浏览器原生「磁吸」效果!Anchor Positioning 锚点定位神器解析
阅读排行:
· DeepSeek 开源周回顾「GitHub 热点速览」
· 物流快递公司核心技术能力-地址解析分单基础技术分享
· .NET 10首个预览版发布:重大改进与新特性概览!
· AI与.NET技术实操系列(二):开始使用ML.NET
· 单线程的Redis速度为什么快?
历史上的今天:
2018-08-28 SYS.AUD$无法扩容导致无法登录的问题
点击右上角即可分享
微信分享提示