屬性的字符串。
-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/nginx Benchmarking www.baidu.com (be patient)…..doneapache 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 ###每秒的網絡流量cookie 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性能指標
在進行性能測試過程當中有幾個指標比較重要：
一、吞吐率（Requests per second）
服務器併發處理能力的量化描述，單位是reqs/s，指的是在某個併發用戶數下單位時間內處理的請求數。某個併發用戶數下單位時間內能處理的最大請求數，稱之爲最大吞吐率。
記住：吞吐率是基於併發用戶數的。這句話表明了兩個含義：
a、吞吐率和併發用戶數相關
b、不一樣的併發用戶數下，吞吐率通常是不一樣的
計算公式：總請求數/處理完成這些請求數所花費的時間，即
Request per second=Complete requests/Time taken for tests
必需要說明的是，這個數值表示當前機器的總體性能，值越大越好。
二、併發鏈接數（The number of concurrent connections）
併發鏈接數指的是某個時刻服務器所接受的請求數目，簡單的講，就是一個會話。
三、併發用戶數（Concurrency Level）
要注意區分這個概念和併發鏈接數之間的區別，一個用戶可能同時會產生多個會話，也即鏈接數。在HTTP/1.1下，IE7支持兩個併發鏈接，IE8支持6個併發鏈接，FireFox3支持4個併發鏈接，因此相應的，咱們的併發用戶數就得除以這個基數。
四、用戶平均請求等待時間（Time per request）
計算公式：處理完成全部請求數所花費的時間/（總請求數/併發用戶數），即：
Time per request=Time taken for tests/（Complete requests/Concurrency Level）
五、服務器平均請求等待時間（Time per request:across all concurrent requests）
計算公式：處理完成全部請求數所花費的時間/總請求數，即：
Time taken for/testsComplete requests
能夠看到，它是吞吐率的倒數。
同時，它也等於用戶平均請求等待時間/併發用戶數，即
Time per request/Concurrency Level併發 具體實際案例可參考 Tengine & Nginx性能測試app http://tengine.taobao.org/document_cn/benchmark_cn.htmlsocket 背景
咱們在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的相應配置。 statusTengine相比Nginx默認配置，提高200%的處理能力。Tengine相比Nginx優化配置，提高60%的處理能力。 |