标签：原因 很多 不能 问题 时间 大量 请求 0ms 接收
思考：网络性能优化：网络 -- cpu -- 线程数 -- 单个任务耗时 --- qps --- 并发
如果没有理清楚上述概念和它们之间的关系，那么优化会毫无章法；
线程越多，利用上的线程越多，cpu的idle会约低，只到cpu低得不能再低，一般情况下，可以可劲用（idle为10%你遇到过吗？），但是要注意你的下游能否能扛得住你转嫁给他们的并发压力呢；
单个任务处理越快，qps和并发会越高；
两个线程的并发一定是一个线程的两倍，10个线程的并发一定是2个线程的5倍；
qps是一秒处理的任务数，这个换算逻辑是：假如一个任务是100ms,有10个线程，那么并发是10，qps是(1000/ 100) * 10 = 100,
注意，这里是理想情况下的理论换算，理想的意思是每个任务都是100ms，时间不多不少；
网络都有一个出口，对于请求方来说，出口就是到你的网络服务里面，如果你不接收，或者你接收不了（就那么几个工作线程都还一直忙着呢），那么
对于请求方来说，就会超时（超过预期时间），你可以先接收，后处理，但是如果你单个任务处理能力没有提升，工作线程没有增多，就算接收也是没用的；
所以，对于网络服务所在机器的cpu如果idle很低，有两个原因造成的，一个是单个任务的计算量很大，使用了很多的cpu资源，一个是你接收而且确实同时处理了
大量的并发任务，这些任务并行执行加起来让cpu的idle很低；针对这两种情况，也给了我们解决问题的两个思路：一个是让单个任务处理更高效，耗时更短；一个是
增加我们的线程数，让更多的线程跑起来，让cpu更加忙碌起来；
思考：网络性能优化：网络 -- cpu -- 线程数 -- 单个任务耗时 --- qps --- 并发
标签：原因 很多 不能 问题 时间 大量 请求 0ms 接收
原文地址：https://www.cnblogs.com/big1987/p/11053925.html
