QPS,RT，并发线程数

计算方式

QPS=并发数/RT 或者 并发数=QPS*RT

举个栗子：

假设公司每天早上9点到10点1个小时内都有员工要上厕所，公司有3600个员工，平均每个员工上厕所时间为10分钟，我们来计算一下。

QPS = 3600/60*60 1

RT = 10*60 600秒

并发数 = 1 * 600 600

这样就意味着如果想达到最好的蹲坑体验，公司需要600个坑位来满足员工需求，否则的话上厕所就要排队等待了。

性能思考

按照QPS=并发数/RT公式，假设我们现在是单线程的场景，那么QPS公式应该是这样：QPS=1/RT，实际上RT应该=CPU time + CPU wait time，如果将线程数提高到2，那么QPS=2/(CPU time + CPU wait time)，那么是否意味着我们只要单纯提高线程数就能提高QPS呢？

最佳线程数计算

假设CPU time是49ms，CPU wait time是200ms，那么QPS=1000ms/249ms=4.01，这里200ms的wait时间我们可以认为CPU一直处于等待状态啥也没干，理论上来说200ms还可以接受200/49≈4个请求，不考虑上下文切换和其他开销的话，可以认为总线程数=(200+49)/49=5，如果再考虑上CPU多核和利用率的问题，我们大致可以认为：最佳线程数=RT/CPU Time * CPU核心数 * CPU利用率

那么最大QPS公式推导为：

最大QPS=最佳线程数*单线程QPS=（RT/CPU Time * CPU核心数 * CPU利用率）*（1/RT) = CPU核心数*CPU利用率/CPU time

 

那么这样是否意味着我们只要不停增加CPU核心数就能无限提高QPS呢?

实际上随着请求数量的增加，带来大量的上下文的切换、gc和锁变化。qps更高，产生对象越多，gc越频繁，cpu time和利用率都受到影响，尤其在串行的时候，锁自旋、自适应、偏向等等也成为影响par的因素。

总结，为了提升达到最好的性能，我们需要不断的进行性能测试，调整小城池大小，找到最合适的参数来达到提高性能的目的。