属性的字符串。
-C对请求附加一个Cookie:行。其典型形式是name=value的一个参数对，此参数可以重复。
-H对请求附加额外的头信息。此参数的典型形式是一个有效的头信息行，其中包含了以冒号分隔的字段和值的对(如,”Accept-Encoding:zip/zop;8bit”)。
-A对服务器提供BASIC认证信任。用户名和密码由一个:隔开，并以base64编码形式发送。无论服务器是否需要(即,是否发送了401认证需求代码)，此字符串都会被发送。
-h显示使用方法。
-d不显示”percentage served within XX [ms] table”的消息(为以前的版本提供支持)。
-e产生一个以逗号分隔的(CSV)文件，其中包含了处理每个相应百分比的请求所需要(从1%到100%)的相应百分比的(以微妙为单位)时间。由于这种格式已经“二进制化”，所以比’gnuplot’格式更有用。
-g把所有测试结果写入一个’gnuplot’或者TSV(以Tab分隔的)文件。此文件可以方便地导入到Gnuplot,IDL,Mathematica,Igor甚至Excel中。其中的第一行为标题。
-i执行HEAD请求，而不是GET。
-k启用HTTP KeepAlive功能，即在一个HTTP会话中执行多个请求。默认时，不启用KeepAlive功能。
-q如果处理的请求数大于150，ab每处理大约10%或者100个请求时，会在stderr输出一个进度计数。此-q标记可以抑制这些信息。
ab实际使用
ab的命令参数比较多，我们经常使用的是-c和-n参数。
例如：
[root@nginx1 ~]# ab -n 100 -c 10 http://www.baidu.com/ ###-n：发出的请求数 -c：每次的并发数
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/
Benchmarking www.baidu.com (be patient)…..done
Server Software: BWS/1.0 ###服务器的信息
Server Hostname: www.baidu.com ###域名
Server Port: 80 ###连接的端口
Document Path: / ###请求的URI
Document Length: 10530 bytes ###第一次返回文档的大小。如果文档大小在测试的时候改变了，那么这个响应会视为一个错误。
Concurrency Level: 10 ###并发数
Time taken for tests: 29.32944 seconds ###开始到结束的时间
Complete requests: 100 ###成功的请求数
Failed requests: 42 ###失败的请求数
(Connect: 0, Length: 42, Exceptions: 0) ###详细的多少个连接失败，长度异常，读取失败
Write errors: 0 ###在发送的时候失败的次数
Total transferred: 1131908 bytes ###从服务器接收的字节数。这是明确的网络发送字节。
HTML transferred: 1084140 bytes ###html内容传输量
Requests per second: 3.44 [#/sec] (mean) ###每秒请求数
Time per request: 2903.294 [ms] (mean) ###每个并发的时间
Time per request: 290.329 [ms] (mean, across all concurrent requests) ###个人理解是每个并发中每个请求的时间
Transfer rate: 38.06 [Kbytes/sec] received ###每秒的网络流量
Connection Times (ms)
min mean[+/-sd] median max
Connect: 37 1003 809.6 898 4056 ###socket发出请求到建立连接所花的时间。
Processing: 253 1713 861.2 1800 5643 ###连接建立后，直到http全部接收所用的时间。
Waiting: 42 759 711.5 715 4886 ###发送http完后，到接到第一个byte所等待的时间。
Total: 336 2717 1248.4 2739 6655 ###conn+processing
ab性能指标
在进行性能测试过程中有几个指标比较重要：
1、吞吐率（Requests per second）
服务器并发处理能力的量化描述，单位是reqs/s，指的是在某个并发用户数下单位时间内处理的请求数。某个并发用户数下单位时间内能处理的最大请求数，称之为最大吞吐率。
记住：吞吐率是基于并发用户数的。这句话代表了两个含义：
a、吞吐率和并发用户数相关
b、不同的并发用户数下，吞吐率一般是不同的
计算公式：总请求数/处理完成这些请求数所花费的时间，即
Request per second=Complete requests/Time taken for tests
必须要说明的是，这个数值表示当前机器的整体性能，值越大越好。
2、并发连接数（The number of concurrent connections）
并发连接数指的是某个时刻服务器所接受的请求数目，简单的讲，就是一个会话。
3、并发用户数（Concurrency Level）
要注意区分这个概念和并发连接数之间的区别，一个用户可能同时会产生多个会话，也即连接数。在HTTP/1.1下，IE7支持两个并发连接，IE8支持6个并发连接，FireFox3支持4个并发连接，所以相应的，我们的并发用户数就得除以这个基数。
4、用户平均请求等待时间（Time per request）
计算公式：处理完成所有请求数所花费的时间/（总请求数/并发用户数），即：
Time per request=Time taken for tests/（Complete requests/Concurrency Level）
5、服务器平均请求等待时间（Time per request:across all concurrent requests）
计算公式：处理完成所有请求数所花费的时间/总请求数，即：
Time taken for/testsComplete requests
可以看到，它是吞吐率的倒数。
同时，它也等于用户平均请求等待时间/并发用户数，即
Time per request/Concurrency Level
具体实际案例可参考 Tengine & Nginx性能测试
http://tengine.taobao.org/document_cn/benchmark_cn.html
背景
我们在Tengine中实现了SO_REUSEPORT [1]的支持。为了查看其效果，我们进行了一个简单的测试。我们在同一个局域网中部署了一共四台同等配置的服务器，其中一台同时部署Tengine和Nginx，分别监听不同的端口，另外三台部署ab，三个ab同时压测，从总并发100逐步递增到1000，分别压测Tengine和Nginx，访问空gif图片。
三种压测场景：
Tengine打开SO_REUSEPORT，reuse_port on。
Nginx默认配置。
Nginx优化配置，关闭mutex锁，accept_mutex off。
ab压测命令：
ab -r -n 10000000 -c 100 http://ip:81/empty.gif
测试环境
Intel(R)Xeon(R)E5-2650v2@2.60GHz 32core
Intel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Connection
Red Hat Enterprise Linux Server release 5.7 (Tikanga)
linux-3.17.2.x86_64
128GB Memroy
软件
Nginx/1.6.2
Tengine/2.1.0 (http://tengine.taobao.org)
ApacheBench/2.3
系统配置
net.ipv4.tcp_mem = 3097431 4129911 6194862
net.ipv4.tcp_rmem = 4096 87380 6291456
net.ipv4.tcp_wmem = 4096 65536 4194304
net.ipv4.tcp_max_tw_buckets = 262144
net.ipv4.tcp_tw_recycle = 0
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_fin_timeout = 15
net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.tcp_max_syn_backlog = 65535
net.core.somaxconn = 65535
net.core.netdev_max_backlog = 200000
Limit Soft Limit Hard Limit Units
Max open files 65535 65535 files
服务器配置
Nginx/1.6.2 配置文件：
worker_processes auto;
worker_cpu_affinity
00000000000000000000000000000001
00000000000000000000000000000010
00000000000000000000000000000100
00000000000000000000000000001000
00000000000000000000000000010000
00000000000000000000000000100000
00000000000000000000000001000000
00000000000000000000000010000000
00000000000000000000000100000000
00000000000000000000001000000000
00000000000000000000010000000000
00000000000000000000100000000000
00000000000000000001000000000000
00000000000000000010000000000000
00000000000000000100000000000000
00000000000000001000000000000000
00000000000000010000000000000000
00000000000000100000000000000000
00000000000001000000000000000000
00000000000010000000000000000000
00000000000100000000000000000000
00000000001000000000000000000000
00000000010000000000000000000000
00000000100000000000000000000000
00000001000000000000000000000000
00000010000000000000000000000000
00000100000000000000000000000000
00001000000000000000000000000000
00010000000000000000000000000000
00100000000000000000000000000000
01000000000000000000000000000000
10000000000000000000000000000000
;
worker_rlimit_nofile 65535;
events {
worker_connections 65535;
accept_mutex off;
}
http {
include mime.types;
default_type application/octet-stream;
access_log logs/access.log;
keepalive_timeout 0;
server {
listen 82 backlog=65535;
server_name localhost;
location = /empty.gif {
empty_gif;
}
}
}
Tengine/2.1.0配置文件：
worker_processes auto;
worker_cpu_affinity auto;
worker_rlimit_nofile 65535;
events {
worker_connections 65535;
reuse_port on;
}
http {
include mime.types;
default_type application/octet-stream;
access_log logs/access.log;
keepalive_timeout 0;
server {
listen 81 backlog=65535;
server_name localhost;
location = /empty.gif {
empty_gif;
}
}
}
Tengine和Nginx只有reuse_port和accept_mutex两处配置不同。
Tengine的worker_cpu_affinity等同于Nginx的相应配置。
status
Tengine相比Nginx默认配置，提升200%的处理能力。
Tengine相比Nginx优化配置，提升60%的处理能力。
|
