本文探讨了提高服务器每秒处理请求数（q）的方法，包括降低平均响应时间（t）和增加并发量（c）。通过优化代码来减少t可能效果有限，而增加c可能导致上下文切换开销增大。介绍了线程/进程模型对并发量的影响，以及在特定业务场景下，使用NIO模式如何提升并发能力。强调了找到合适并发量的重要性，以及针对‘小数据量、较长返回时间’业务的服务优化策略。
不是同一个概念，但它们之间有联系：
设平均响应时间为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利用率;
当然这一切的前提是该业务具有“小数据量、较长返回时间”的特征
863
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
