吞吐率:一般使用单位时间内服务器处理的请求数来描述服务器并发处理能力,单位是“reqs/s”

通过开启Apache的mod_status模块,查看当前服务器的运行状况及吞吐率。

开启Apache的mod_status模块的方法:

httpd.conf文件

LoadModule status_module modules/mod_status.so 去掉前面的#,并在文件底部添加:

<location /server-status>
  SetHandler server-status
  Order Deny,Allow
  Deny from nothing
  Allow from all
</location>
ExtendedStatus On

重启服务器。

浏览器输入:http://localhost/server-status

服务器并发处理能力——吞吐率-风君雪科技博客

159 requests/sec是此时的吞吐率。5 requests是此时的并发用户数。

并发用户数:在某一时刻同时向服务器发送请求的用户总数。

在考虑实际用户规模的时候,我们需要考虑到,用户访问Web站点通常使用浏览器,而浏览器在下载一个网页以及网页中的多个组件时,采用多线程的并发下载方式,但是对于同一个域名下URL的并发下载数是有最大限制的,具体限制视浏览器的不同而不同。以下是在HTTP/1.1下不同浏览器的并发数:

服务器并发处理能力——吞吐率-风君雪科技博客

所以,服务器所支持的最大并发数,具体到真实的用户,可能并不是一对一的关系,一个真实的用户可能会给服务器带来两个或更多的并发用户数压力。

从web服务器角度来看,web服务器一般会限制同时服务的最多用户数,比如Apache的MaxClients参数,所以实际的并发用户数,有时候大于服务器的并发连接数,而多出的用户请求,则在服务器内核的数据接收缓冲区中等待处理,所以这些请求在用户看来处于阻塞状态。

请求等待时间

假设并发用户数为100,这时服务器一般会采用多进程或多线程的并发模型,通过多个执行流来同时处理多个并发用户的请求,而多执行体系的设计原则是轮流交错使用CPU时间片,所以每个执行流花费的时间都被拉长。对每个用户而言,每个请求的平均等待时间会增加;对服务器而言,如果并发策略得当,每个请求的平均处理时间可能减少。、

ab压力测试

ab可以直接在Web服务器本地发起测试请求。

ab进行一切测试的本质都是基于HTTP的。

[root@iZ23elnq9m3Z bin]# ./ab -n1000 -c400 http://www.abc.com/index.php?c=customer&a=index&area=-1&signtime=36&status=0
[1] 12341
[2] 12342
[3] 12343
[4] 12344
[root@iZ23elnq9m3Z bin]# This is ApacheBench, Version 2.3 <$Revision: 1706008 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking www.myidns.com (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests


Server Software:        Apache
Server Hostname:        www.abc.com
Server Port:            80

Document Path:          /index.php?c=customer
Document Length:        0 bytes

Concurrency Level:      400
Time taken for tests:   3.283 seconds
Complete requests:      1000
Failed requests:        0
Non-2xx responses:      1000
Total transferred:      360000 bytes
HTML transferred:       0 bytes
Requests per second:    304.64 [#/sec] (mean)
Time per request:       1313.040 [ms] (mean)
Time per request:       3.283 [ms] (mean, across all concurrent requests)
Transfer rate:          107.10 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0   14  83.8      0    1000
Processing:     8  742 980.4    254    3272
Waiting:        1  741 980.5    252    3272
Total:         43  756 981.4    255    3278

Percentage of the requests served within a certain time (ms)
  50%    255
  66%    264
  75%   1242
  80%   1539
  90%   3099
  95%   3190
  98%   3248
  99%   3269
 100%   3278 (longest request)

[1]   Done                    ./ab -n1000 -c400 http://www.abc.com/index.php?c=customer
[2]   Done                    a=index
[3]-  Done                    area=-1
[4]+  Done                    signtime=36

 启动ab时,传入三个命令行参数:

-n1000 表示总请求数1000;

-c400 表示并发用户数;

http://xxx 标签请求的目标URL。

Requests per second:    304.64 [#/sec] (mean)  #吞吐率
Time per request: 1313.040 [ms] (mean) #用户平均请求等待时间
Time per request: 3.283 [ms] (mean, across all concurrent requests) #服务器平均请求处理时间,也是吞吐率的倒数
Transfer rate: 107.10 [Kbytes/sec] received #这些请求在单位时间内从服务器获取的数据长度,可以说明服务器在处理能力达到极限时,其出口带宽的需求量

 对不同并发用户数的吞吐率测试结果:

并发用户数 吞吐率(reqs/s) 请求等待时间(ms) 请求处理时间(ms)
1 266.36 3.754 3.754
2 506.03 3.952 1.976
5 530.49 9.425 1.885
10 530.94 18.935 1.883
20 539.37 37.081 1.854
50 530.30 94.285 1.886
100 538.51 185.697 1.857
150 322.46 465.169 3.101
200 538.78 373.285 1.866
300 81.02 3702.955 12.343
400 304.64 1313.040 3.283
500 302.55 1652.642 3.305

 影响上面三个指标的因素,除去服务器的硬件配置,就是并发策略了,并不存在一个对所有性质的请求都高效的并发策略。