我的應用程式在負載下遇到了問題,在運行一些負載測試後,我意識到當我直接在http
連接埠上對應用程式伺服器進行負載測試時8080
,應用程式伺服器響應相當快。
當我透過點擊網域名稱並使用 進行負載測試時https
,即我點擊的 endint 是https://load.api.example.in
,回應時間增加了大約 5 倍。
這讓我得出結論,中間的 haproxy 是一個瓶頸。
我增加了haproxy的伺服器大小,在重負載下,CPU利用率出現峰值,但由於伺服器較大,只有50%左右。 (根據AWS監控)
我需要在 haproxy 配置(或其他任何地方)中更改哪些內容才能解決此問題?
我目前的 haproxy 配置(匿名)
global
ulimit-n 99999
maxconn 99999
maxpipes 99999
log 127.0.0.1 local0
log 127.0.0.1 local1 notice
maxconn 4096
tune.ssl.default-dh-param 2048
chroot /var/lib/haproxy
user haproxy
group haproxy
daemon
defaults
log global
mode http
option httplog
option dontlognull
option forwardfor
option http-server-close
retries 3
option redispatch
maxconn 2000
timeout connect 5000
timeout client 50000
timeout server 50000
errorfile 400 /etc/haproxy/errors/400.http
errorfile 403 /etc/haproxy/errors/403.http
errorfile 408 /etc/haproxy/errors/408.http
errorfile 500 /etc/haproxy/errors/500.http
errorfile 502 /etc/haproxy/errors/502.http
errorfile 503 /etc/haproxy/errors/503.http
errorfile 504 /etc/haproxy/errors/504.http
frontend mqtt
bind *:1883
bind *:1884
mode tcp
option clitcpka # TCP Keep-alive
timeout client 3h
timeout server 3h
option tcplog
acl host_mqtt_staging hdr(host) -i staging.mqtt.example.in
acl host_mqtt_staging hdr(host) -i staging.mqtt.example.com
acl host_mqtt hdr(host) -i mqtt.example.in
acl host_mqtt hdr(host) -i mqtt.example.com
use_backend mqtt_staging if host_mqtt_staging
use_backend mqtt if host_mqtt
frontend http
bind *:80
mode http
reqadd X-Forwarded-Proto:\ http
redirect scheme https code 301 if !{ ssl_fc }
frontend https
bind *:443 ssl crt /etc/haproxy/certs/staging.myservice.example-2.com.pem
mode http
reqadd X-Forwarded-Proto:\ https
acl letsencrypt-acl path_beg /.well-known/acme-challenge/
acl host_myservice_staging hdr(host) -i staging.api.example.in
acl host_myservice_staging hdr(host) -i staging.api.example.com
acl host_myservice_load hdr(host) -i load.api.example.in
use_backend letsencrypt-backend if letsencrypt-acl
use_backend myservice_staging if host_myservice_staging
use_backend myservice_load if host_myservice_load
default_backend api
backend letsencrypt-backend
server letsencrypt 127.0.0.1:54321
backend api
balance roundrobin
option httpclose
option forwardfor
server web00 app00.staging.internal.example-2.com:8080 check
backend myservice_staging
balance roundrobin
option httpclose
option forwardfor
server myservice00 myservice00.staging.internal.example-2.com:8080 check weight 1
backend myservice_load
balance roundrobin
option httpclose
option forwardfor
server myserviceload00 load00.staging.internal.example-2.com:8080 check weight 1
backend mqtt_staging
balance leastconn
server mqttdev00 mqtt00.internal.example-2.com:1883 check
backend mqtt
balance leastconn
server prodmqttdev00 prodmqtt00.internal.example-2.com:1883 check
回應時間
- 使用 haproxy:平均超過 3 秒
- 不使用 haproxy:平均 500-600 毫秒
更新:
在測試時,我更新了我的 haproxy 配置,將 http 轉送到 https 中已配置的相同後端。透過此更改,我的負載測試(透過 http 上的 haproxy)以及我將所有請求直接發送到伺服器的負載測試都執行了。
因此,我非常確定問題(或幾個問題中最大的問題)是haproxy中的ssl配置。關於我應該嘗試改變什麼來提高效能有什麼建議嗎?
答案1
由於您已經在使用 AWS,請使用 ELB+AWS Certificate Manager 為您執行 SSL。以 http 模式運行 Haproxy 並忽略該問題。
或開始使用以下 Haproxy 選項:
tune.ssl.cachesize
tune.ssl.lifetime
ciphers
defer-accept
force-tlsv12
也嘗試在後端使用靜態頁面,最好在同一台主機上。限制測試期間應用程式的影響。