(转)并发-Tomcat线程-QPS的思考

转自：https://segmentfault.com/q/1010000016846975该贴下临风的回答

临风个人主页：https://segmentfault.com/u/linfeng_5ac9bd0a4d6a7

一般线程数有一个公式：最佳启动线程数 = [任务执行时间 / (任务执行时间 - IO等待时间)] * CPU内核数

比如说任务执行时间是100ms IO等待时间是10ms 8核 则线程数为8个

IO等待时间是50ms 则线程数为16个

线程多少对最高并发没有直接影响，任务计算时间才是影响最高并发数的根本原因。
当任务的执行时间减小，那么服务器每秒处理的请求就会增加，也就是说支持的并发变大。

比如你在服务端只是简单的return ok;,稍微正常一点服务器上的Tomcat都能达到5000甚至10000的并发。

只不过在大多数的web应用中，任务执行时间并不会太短，而且还涉及到数据库操作，所以大部分情况下Tomcat的最高并发就只有几百。

对于相同的任务执行时间，在不同的IO模型和线程模型中最高并发也表现的不一样。
在BIO模型中，线程数 = 链接数，并发增加会造成线程数一定程度的增加，CPU就要花费一点时间在线程切换上。
在NIO模型中，并发并不会造成线程的增加，可以维持最佳线程数，从而提高CPU的利用率，在一定程度上提高最高并发。
Tomcat已经实现了NIO模型，在7.x版本中需要配置，8.x版本使用NIO作为默认的模型。

 

补充：
上面的回答的不好，补充一下。
题主应该这么问，tomcat只能支持几百个并发的原因是什么？

其实跟线程关系不大，暂且以1秒内服务器处理的请求数来衡量并发数，那么最大并发就是1秒内服务器最多能处理的请求数

很显然，平均单个请求处理时间越短，则最大并发越高。平均请求处理时间直接影响了最大并发的高度。

而大部分情况下Tomcat处理请求的平均时间不会太短，有时还涉及数据库操作，所以大部分情况下Tomcat的最高并发就只有几百。
然后线程模型会影响Tomcat处理请求的平均时间，要么是线程太少造成CPU等待而增加了平均处理时间，要么是线程太多而造成CPU要花费一定的周期来进行线程切换而延长了平均处理时间。所以合理的设置线程数能一定程度提高最大并发。
那么怎么提高最大并发呢？
思路当然是减少平均请求处理时间，比如说优化算法，动静分离，缓存，异步等等手段。

 

“某个时间点上同时运行”这是并行的概念，衡量一个网站的性能不能用并行去衡量，没听过描述一个网站性能是这样描述的“网站同一时刻能处理多少请求”，都是说某网站在一段时间最多能处理多少请求。

redis是单线程模型的，但它的最高并发能达到10w+，因为他是纯内存操作，每个请求的处理时间短

web项目除了要访问数据库，还要访问硬盘上的页面，还要调用网络上的服务（所以tomcat需要多线程来充分利用计算资源以弥补数据等待的时间），必然相同的一段时间redis要比tomcat处理的事物数要多得多。

但二者处理的业务场景是不同的，所以tomcat最大并发上不去是因为他的业务场景决定，但是可以通过一些手段来提升性能，比如业务处理的算法，tomcat的线程模型和网络模型优化等等，但这些是不能让tomcat变得像redis一样性能高。

并发量 指的是某一段时间客户的平均请求数，并不是某一时刻的并行请求数，这根服务端没关系的，最大并发量才是衡量服务性能的关键，指的是服务最多能承受并发量的一个范围。

并发量和qps有啥区别？

并发量是客户端的事情，有多少并发量取决于有多少客户端并发访问，qps是服务端的指标，服务端每秒处理请求数。

当并发量较小的时候，服务器有足够的能力来处理请求，这时 qps=并发量

当并发量增多，qps也随之增长，当并发量达到一个临界值，服务端处理能力达到极限，由于服务端需要处理额外的事情，比如线程切换等等，qps略微下降，当兵发量再继续上升，由于请求堆积严重，可能导致服务端崩溃，qps急剧下降
另外服务端还有一个指标，响应时间。并发量是输入，qps和响应时间是输出，他们之间有个曲线图，在李智慧那本“大型网站技术架构：核心原理与案例分析”书上有分析。