nginx - 每秒处理请求数和并发是一个概念吗？

Question

windows用apache的ab测试了服务器

ab -c 100 -n 1000 http://www.xxxxx.com

发现 每秒处理请求数只有20，其他的等待 不是说nginx默认的并发量很高么？

还是每秒处理请求数和并发不是一个概念。

每秒处理数 并发 压力测试 求疏通。。。

Answer 1

只说一台服务器的情况。
并发数是指同时到达的请求数量，这是从客户端的角度来说的；服务器并发处理能力则是指服务器能同时处理多少个请求，理想情况下（在无进程切换的情况下），并发处理能力等于cpu的核数。
基于上面说的，假如有8核，并且请求的任务都是无io的纯计算任务，那明显每个核每秒的处理能力不止一个请求，假设每秒能处理10000个（简单的计算任务的话，这个数量完全是有可能的），那这个服务器就能处理每秒80000的请求数。
现在再加上io，如果io的时候cpu必须等待，且不能做其他事，那显然cpu每秒能处理的请求数将大大下降，可能会从10000个降到几百个甚至几十个或几个。
接下来可以加上进程切换、算法效率等各种因素，把这些因素一个一个地加上去之后，就能得到一个复杂的但真实的服务器了。

Answer 2

不是同一个概念，但它们之间有联系：
设平均响应时间为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利用率;
当然这一切的前提是该业务具有“小数据量、较长返回时间”的特征

Answer 3

我们假设你的网站是一个静态站，所有的请求都走nginx，然后需要确认测试机和服务器的网络通信要畅通。ab这种工具对于压力测试来说不是很有说服力，推荐jmeter或者loadrunner。压力测试的时候要保证测试的响应时间曲线稳定住一定时间后，才认为是当前被测试服务器的真实性能，因为刚开始测试的时候需要一定预热时间，一般测试到一定时间之后曲线会稳定住，这时候再判断当前的响应时间。

Answer 4

每秒请求数 = 一段时间完成总的请求数 / 时间

并发量是当前保持的连接数吧，通过netstat -net 查看所有连接。

如：

netstat -ntp |grep -i "80" | wc -l