? 這臺機器已經(jīng)建立了 2.3 萬個 TCP 連接
? 使用內存大約在 22G。
測試目標

我們要測試的組件是 HAProxy 1.6 版。生產(chǎn)環(huán)境是在 4 核 30 G 的機器上運行該軟件，當前所有的連接都是非 SSL 的。
測試目標有兩方面：

1. 當將整個負載從非 SSL 連接轉移到 SSL 連接時，CPU 使用率增加的百分比。CPU 的使用率肯定會增加，這是由于 5 次握手的加長和數(shù)據(jù)包加密的開銷所帶來。
2. 其次，希望能夠測試單個 HAProxy 每秒請求數(shù)和最大并發(fā)連接數(shù)的上限
   組件和配置

? 使用多臺客戶端機器來執(zhí)行 HAProxy 壓力測試。
? 有各種配置的 HAProxy 1.6 的機器
? 4核，30G
? 16核，30G
? 16核，G
? 相關后端服務器，用于支持所有并發(fā)訪問。
HTTP 和 MQTT

我們的整個基礎設施支持兩種協(xié)議：
? HTTP
? MQTT
在我們的技術棧中，沒有使用 HTTP 2.0，因此在 HTTP 上沒有長連的功能。所以在生產(chǎn)環(huán)境中，單個 HAProxy 機器（上行 + 下行）的最大數(shù)量的 TCP 連接在（2 * 150k）左右。雖然并發(fā)連接數(shù)量相當?shù)?，但每秒請求的?shù)量卻相當高。
另一方面，MQTT 是一種不同的通信方式。它提供高質量的服務參數(shù)和持久的連接性。因此，可以在 MQTT 通道上使用雙向長連通信。對于支持 MQTT（底層 TCP）連接的 HAProxy，在高峰時段會看到每臺機器上大約有 600 - 700k 個 TCP 連接。
我們希望進行負載測試，這將為我們提供基于 HTTP 和 MQTT 連接的精確結果。

有很多工具可以幫助我們輕松地測試 HTTP 服務器，并且提供了高級功能，如結果匯總，將文本轉換為圖形等。然而，針對 MQTT，我們找不到任何壓力測試工具。我們確實有一個自己開發(fā)的工具，但是它不夠穩(wěn)定，不足以支持這種負載。

所以我們決定使用客戶端測試 HTTP 負載，并在 MQTT 服務器使用相同配置。
初始化設置

考慮到相關內容對于進行類似的壓力測試或調優(yōu)的人來說有幫助，本文提供了很多相關細節(jié)，篇幅稍微有些長。

? 我們采用了一臺 16 核 30G 機器來運行 HAProxy，考慮到 HAProxy 的 SSL 產(chǎn)生的 CPU 巨大開銷，因此沒有直接使用目前生產(chǎn)環(huán)境。
? 對于服務器端，我們使用了一個簡單的 NodeJs 服務器，它在接收到 ping 請求時用 pong 進行回復。
? 對于客戶端，我們最終使用 Apache Bench。使用 ab 的原因是因為它是一個大家熟悉和穩(wěn)定的負載測試工具，它也提供了很好的測試結果匯總，這正是我們所需要的。

ab 工具提供了許多有用的參數(shù)用于我們的負載測試，如：
? -c，指定訪問服務器的并發(fā)請求數(shù)。
? -n，顧名思義，指定當前負載運行的請求總數(shù)。
? -p，包含 POST 請求的正文（要測試的內容）。

如果仔細觀察這些參數(shù)，您會發(fā)現(xiàn)通過調整所有這三個參數(shù)可以進行很多排列組合。示例 ab 請求將看起來像這樣

ab -S -p post_smaller.txt -T application/json -q -n 100000 -c 3000

? 99％ 的返回請求的響應延遲時間。
? Time per request：每個請求的時間
? No. of failed requests：失敗請求數(shù)。
? Requests per second: 每秒請求量

ab 的最大問題是它不提供控制每秒發(fā)起請求量，因此我們不得不調整 -c 并發(fā)級別以獲得所需的每秒鐘請求數(shù)，并導致很多后文提到的問題和錯誤。
實現(xiàn)haproxy301域名跳轉：

1、acl oldboy_java path_beg /java/
2、acl oldboy_php path_beg /php/
3、use_backend webserver if oldboy_java #如果是java就找webserver這個池
4、use_backend webserver if oldboy_php

實現(xiàn)haproxy基于擴展名做7層跳轉：

1、acl oldboy_pic path_end .gif .png .jpg .css .js
2、use_backend nginxpools if olboy_static or oldboy_pic

實現(xiàn)haproxy基于user_agent做7層跳轉

1、acl iphone_users hdr_sub(user-agent) -i iphone
2、redirect prefix if iphone users
3、acl android_users hdr_sub(user-agent) -i android
4、redirect prefix if android_users

實現(xiàn)haproxy基于ip和端口過濾

1、acl valid_ip src 192.168.1.0/24
2、block if !valid_ip #如果不符合valid_ip的規(guī)則就block拒絕掉

讓haproxy錯誤頁面優(yōu)雅的顯示

errorfile 403 /tec/haproxy/errorfiles/403forbild.html
基于HTTP的直接IP URL方式的健康檢查:
1.>第一種HEAD配置方法

option httpchk HEAD /check.html HTTP/1.0
這種檢測方式就相當于通過curl -i http://127.0.0.1/check.html
或者 wget http://127.0.0.1/check.html訪問地址。
**check.html文件必須在網(wǎng)站根目錄下創(chuàng)建

健康檢查的頻率、時間等參數(shù)：

maxconn 控制節(jié)點的并發(fā)連接的
weight 12 權重，權重越大，請求越多

2.>第二種GET配置方式

GET后端server的web頁面

option httpchk GET /index.html HTTP/1.0

backup 和allbackups參數(shù)：

server web1 10.10.100.66:80 check inter 2000 fall 3 weight 30
server web2 10.10.100.67:80 check inter 2000 fall 3 weight 30
server web3 10.10.100.68:80 check inter 2000 fall 3 weight 30 backup

當web1和web2服務停止后，web3再提供服務，這樣可以達到高可用的目的

option allbackups

server web1 10.10.100.66:80 check inter 2000 fall 3 weight 30
server web2 10.10.100.67:80 check inter 2000 fall 3 weight 30
server web3 10.10.100.68:80 check inter 2000 fall 3 weight 30 backup
server web4 10.10.100.69:80 check inter 2000 fall 3 weight 30 backup

加上 option allbackups后，當web1和web2掛掉后，web3和web4都啟動起來提供服務，不加allbackups則只有一臺提供服務.

haproxy下的RS無法記錄客戶端真實ip的問題

在haproxy配置文件里加入如下參數(shù)：

listen www

    option forwardfor 
    提示：參數(shù)最好放在listen www里面
    然后在nginx日志格式中加"$http_x_forwarded_for"

關于haproxy日志輸出的問題:
CentoS6.5下HAProxy日志配置詳解:

emerg 0　　　　 　　系統(tǒng)不可用
alert 1 　　　　　　必須馬上采取行動的事件
crit 2 　　　　　　 關鍵的事件
err 3 　　　　　　　錯誤事件
warning 4 　　　　　警告事件
notice 5 　　　　　普通但重要的事件
info 6 　　　　　　有用的信息
debug 7 　　　　　調試信息

vim haproxy.conf(在default處添加如下信息)

########################################
defaults
log global
option httplog
log 127.0.0.1 local3
########################################

vim /etc/rsyslog.conf(添加如下內容)

local3.* /var/log/haproxy.log

vim /etc/sysconfig/rsyslog

把SYSLOGD_OPTIONS="-m 0"
改成 SYSLOGD_OPTIONS="-r -m 0"

相關解釋說明:
-r: 　打開接受外來日志消息的功能,其監(jiān)控514 UDP端口;
-x: 關閉自動解析對方日志服務器的FQDN信息,這能避免DNS不完整所帶來的麻煩;
-m: 修改syslog的內部mark消息寫入間隔時間(0為關閉),例如240為每隔240分鐘寫入一次"--MARK--"信息;
-h: 默認情況下,syslog不會發(fā)送從遠端接受過來的消息到其他主機,而使用該選項,則把該開關打開,所有接受到的信息都可根據(jù)syslog.conf中定義的@主機轉發(fā)過去.　　
配置完畢后關閉sellinux然后重啟rsyslog和haproxy 即可.

/etc/init.d/rsyslog restart

haproxy實現(xiàn)負載均衡的方式：
haproxy + heartbeat
haproxy + keepalive

haproxy 的配置文件由兩部分組成：全局設定和對代理的設定，共分為五段：global，defaults，frontend，backend，listen
1.global: (全局配置主要用于設定義全局參數(shù)，屬于進程級的配置，通常和操作系統(tǒng)配置有關)
2.default : (配置默認參數(shù)，這些參數(shù)可以被用到frontend，backend，Listen組件)
在此部分中設置的參數(shù)值，默認會自動引用到下面的frontend、backend、listen部分中，因引，某些參數(shù)屬于公用的配置，只需要在defaults部分添加一次即可。而如果frontend、backend、listen部分也配置了與defaults部分一樣的參數(shù)，Defaults部分參數(shù)對應的值自動被覆蓋。
3.frontend：( 接收請求的前端虛擬節(jié)點，F(xiàn)rontend可以更加規(guī)則直接指定具體使用后端的backend)
frontend是在haproxy 1.3版本以后才引入的一個組件，同時引入的還有backend組件。通過引入這些組件，在很大程度上簡化了haproxy配置文件的復雜性。forntend可以根據(jù)ACL規(guī)則直接指定要使用的后端backend
4.backend : (后端服務集群的配置，真實服務器，一個Backend對應一個或者多個實體服務器)
在HAProxy1.3版本之前，HAProxy的所有配置選項都在這個部分中設置。為了保持兼容性，haproxy新的版本依然保留了listen組件配置試。兩種配置方式任選一中
5.Listen : (Fronted和backend的組合體) 比如haproxy實例狀態(tài)監(jiān)控部分配置
global部分配置說明
通常主要定義全局配置主要用于設定義全局參數(shù)，屬于進程級的配置，通常和操作系統(tǒng)配置有關。

global
log 127.0.0.1 local3 #定義haproxy日志輸出設置
log 127.0.0.1 local1 notice
#log loghost local0 info #定義haproxy 日志級別
ulimit-n 82000 #設置每個進程的可用的最大文件描述符
maxconn 20480 #默認最大連接數(shù)
chroot /usr/local/haproxy #chroot運行路徑
uid 99 #運行haproxy 用戶 UID
gid 99 #運行haproxy 用戶組gid
daemon #以后臺形式運行harpoxy
nbproc 1 #設置進程數(shù)量
pidfile /usr/local/haproxy/run/haproxy.pid #haproxy 進程PID文件
#debug #haproxy調試級別，建議只在開啟單進程的時候調試
#quiet

defaults部分配置說明

用于設置配置默認參數(shù)，這些參數(shù)可以被用到frontend，backend，Listen組件；
此部分中設置的參數(shù)值，默認會自動引用到下面的frontend、backend、listen部分中，因引，某些參數(shù)屬于公用的配置，只需要在defaults部分添加一次即可。而如果frontend、backend、listen部分也配置了與defaults部分一樣的參 數(shù)，Defaults部分參數(shù)對應的值自動被覆蓋；
defaults
log global #引入global定義的日志格式
mode http #所處理的類別(7層代理http，4層代理tcp)
maxconn 50000 #最大連接數(shù)
option httplog #日志類別為http日志格式
option httpclose #每次請求完畢后主動關閉http通道
option dontlognull #不記錄健康檢查日志信息
option forwardfor #如果后端服務器需要獲得客戶端的真實ip，需要配置的參數(shù)，
可以從http header 中獲取客戶端的IP
retries 3 #3次連接失敗就認為服務器不可用，也可以通過后面設置

     option redispatch  

#《---上述選項意思是指serverID 對應的服務器掛掉后，強制定向到其他健康的服務器, 當使用了 cookie時，
haproxy將會將其請求的后端服務器的serverID插入到cookie中，以保證會話的SESSION持久性；而此時，如果
后端的服務器宕掉了,但是客戶端的cookie是不會刷新的，如果設置此參數(shù)，將會將客戶的請求強制定向到另外一個
后端server上，以保證服務的正常---》

     stats refresh 30       #設置統(tǒng)計頁面刷新時間間隔
     option abortonclose    #當服務器負載很高的時候，自動結束掉當前隊列處理比較久的連接
     balance roundrobin     #設置默認負載均衡方式，輪詢方式
     #balance source        #設置默認負載均衡方式，類似于nginx的ip_hash      
     #contimeout 5000        #設置連接超時時間
     #clitimeout 50000       #設置客戶端超時時間
     #srvtimeout 50000       #設置服務器超時時間
     timeout http-request    10s  #默認http請求超時時間
     timeout queue           1m   #默認隊列超時時間
     timeout connect         10s  #默認連接超時時間
     timeout client          1m   #默認客戶端超時時間
     timeout server          1m   #默認服務器超時時間
     timeout http-keep-alive 10s  #默認持久連接超時時間
     timeout check           10s  #設置心跳檢查超時時間

mode http：設置haproxy的運行模式，有三種｛http|tcp|health｝。注意：如果haproxy中還要使用4層的應用（mode tcp）的話，不建議在此定義haproxy的運行模式。
設置HAProxy實例默認的運行模式有tcp、http、health三種可選：
tcp模式：在此模式下，客戶端和服務器端之前將建立一個全雙工的連接，不會對七層報文做任何檢查，默認為tcp模式，經(jīng)常用于SSL、SSH、SMTP等應用。
http模式：在此模式下，客戶端請求在轉發(fā)至后端服務器之前將會被深度分板，所有不與RFC格式兼容的請求都會被拒絕。
health：已基本不用了。

1.roundrobin：基于權重進行的輪叫算法，在服務器的性能分布經(jīng)較均勻時這是一種最公平的，最合量的算法。
2.static-rr：也是基于權重時行輪叫的算法，不過此算法為靜態(tài)方法，在運行時調整其服務權重不會生效。
3.source：是基于請求源IP的算法，此算法對請求的源IP時行hash運算，然后將結果與后端服務器的權理總數(shù)相除后轉發(fā)至某臺匹配的后端服務器，這種方法可以使用一個客戶端IP的請求始終轉發(fā)到特定的后端服務器。
4.leastconn：此算法會將新的連接請求轉發(fā)到具有最少連接數(shù)目的后端服務器。在會話時間較長的場景中推薦使用此算法。例如數(shù)據(jù)庫負載均衡等。此算法不適合會話較短的環(huán)境，如基于http的應用。
5.uri：此算法會對部分或整個URI進行hash運算，再經(jīng)過與服務器的總權重要除，最后轉發(fā)到某臺匹配的后端服務器上。
6.uri_param：此算法會椐據(jù)URL路徑中的參數(shù)時行轉發(fā)，這樣可以保證在后端真實服務器數(shù)量不變時，同一個用戶的請求始終分發(fā)到同一臺機器上。
7.hdr：此算法根據(jù)httpd頭時行轉發(fā)，如果指定的httpd頭名稱不存在，則使用roundrobin算法進行策略轉發(fā)。
8.rdp-cookie(name)：示根據(jù)據(jù)cookie(name)來鎖定并哈希每一次TCP請求。
frontend部分配置說明
frontend是在haproxy 1.3版本以后才引入的一個組件，同時引入的還有backend組件。通過引入這些組件，在很大程度上簡化了haproxy配置文件的復雜性。frontend根據(jù)任意 HTTP請求頭內容做ACL規(guī)則匹配,然后把請求定向到相關的backend

frontend http_80_in
bind 0.0.0.0:80 #設置監(jiān)聽端口，即haproxy提供的web服務端口，和lvs的vip 類似
mode http #http 的7層模式
log global #應用全局的日志設置
option httplog #啟用http的log
option httpclose #每次請求完畢后主動關閉http通道，HAproxy不支持keep-alive模式
option forwardfor #如果后端服務器需要獲得客戶端的真實IP需要配置此參數(shù)，將可以從HttpHeader中獲得客戶端IP
default_backend wwwpool #設置請求默認轉發(fā)的后端服務池

frontend http_80_in：定義一個名為http_80_in的frontend。
bind 0.0.0.0:80：定義haproxy前端部分監(jiān)聽的端口。
mode http：定義為http模式。
log global：繼承global中l(wèi)og的定義。
option forwardfor：使后端server獲取到客戶端的真實IP。
backend部分配置說明
用來定義后端服務集群的配置，真實服務器，一個Backend對應一個或者多個實體服務器

backend wwwpool #定義wwwpool服務器組。
mode http #http的7層模式
option redispatch
option abortonclose
balance source #負載均衡的方式，源哈希算法
cookie SERVERID #允許插入serverid到cookie中，serverid后面可以定義
option httpchk GET /test.html #心跳檢測
server web1 10.1.1.2:80 cookie 2 weight 3 check inter 2000 rise 2 fall 3 maxconn 8
listen部分配置說明
常常用于狀態(tài)頁面監(jiān)控，以及后端server檢查，是Fronted和backend的組合體。
如下為haproxy訪問狀態(tài)監(jiān)控頁面配置：
listen admin_status #Frontend和Backend的組合體,監(jiān)控組的名稱，按需自定義名稱
bind 0.0.0.0:8888 #監(jiān)聽端口
mode http #http的7層模式
log 127.0.0.1 local3 err #錯誤日志記錄
stats refresh 5s #每隔5秒自動刷新監(jiān)控頁面
stats uri /admin?stats #監(jiān)控頁面的url訪問路徑
stats realm itnihao\ welcome #監(jiān)控頁面的提示信息
stats auth admin:admin #監(jiān)控頁面的用戶和密碼admin,可以設置多個用戶名
stats auth admin1:admin1 #監(jiān)控頁面的用戶和密碼admin1
stats hide-version #隱藏統(tǒng)計頁面上的HAproxy版本信息
stats admin if TRUE #手工啟用/禁用,后端服務器(haproxy-1.4.9以后版本)

haproxy日志中的 CD SD問題：增大下邊兩個配置的時間；
timeout client 8h
timeout server 8h
碰到with 或者別的狀態(tài)時修改

timeout http-keep-alive 10s
timeout check 10s
timeout http-request 10s
timeout queue 1m
timeout connect 10s

以上內容，如有問題 隨時溝通
QQ: 936172842