Мне не удается получить более 11 тыс. Запросов в секунду на один экземпляр haproxy.
У меня есть два экземпляра haproxy на Amazon EC2. Оба находятся под экземпляром c4.xlarge. Я безуспешно пытался настроить параметр maxconn, отображение процессора и ограничение linux.
Я использую jmeter для проведения тестов, и если я запускаю два параллельных jmeter, настроенных для атаки одного из haproxy, каждый из которых мне удается получить около 22 КБ, но если я выполняю ту же конфигурацию, но оба атакуют только 1 экземпляр haproxy, максимальная пропускная способность составляет 11 КБ. .
Моя конфигурация haproxy:
global
nbproc 4
cpu-map 1 0
cpu-map 2 1
cpu-map 3 2
cpu-map 4 3
maxconn 150000
log /dev/log local0
log /dev/log local1 notice
chroot /var/lib/haproxy
stats socket /run/haproxy/admin.sock mode 660 level admin
stats timeout 30s
user haproxy
group haproxy
daemon
# Default SSL material locations
ca-base /etc/ssl/certs
crt-base /etc/ssl/private
# Default ciphers to use on SSL-enabled listening sockets.
# For more information, see ciphers(1SSL). This list is from:
# https://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/
# An alternative list with additional directives can be obtained from
# https://mozilla.github.io/server-side-tls/ssl-config-generator/?server=haproxy
ssl-default-bind-ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:!aNULL:!MD5:!DSS
ssl-default-bind-options no-sslv3
defaults
log global
mode http
option httplog
option dontlognull
option http-server-close
retries 2
timeout http-request 10s
timeout queue 1m
timeout connect 5s
timeout client 1m
timeout server 1m
timeout http-keep-alive 20s
timeout check 15s
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 DSP_FRONT
bind *:80
maxconn 300000
default_backend DSP_BACK
backend DSP_BACK
balance hdr(device)
mode http
server dsp1 172.31.3.141:80 check
server dsp2 172.31.8.195:80 check
server dsp3 172.31.8.186:80 check
listen stats
bind :9000
mode http
stats enable
stats hide-version
stats realm HAproxy-Statistics
stats uri /haproxy_stats
Бэкэнд должен быть очень быстрым, а длина ответа - небольшой (0,5–1 КБ).
Также я пытался нарушить системные ограничения.
fs.file-max = 10000000
fs.nr_open = 10000000
net.ipv4.tcp_mem = 786432 1697152 1945728
net.ipv4.tcp_rmem = 4096 4096 16777216
net.ipv4.tcp_wmem = 4096 4096 16777216
net.ipv4.ip_local_port_range = 1000 65535
И добавил лимит файлов в сервис haproxy systemd
LimitNOFILE = 300000
Но вроде бы без изменений.
Я запускаю haproxy под Ubuntu 16.04
Л.Э .:
Вывод cat / proc / [haproxyprocid] / limits
ubuntu@ip-172-31-1-115:~$ ps ax| grep ha
1214 ? Ss 0:00 /usr/sbin/haproxy-systemd-wrapper -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid
1217 ? S 0:00 /usr/sbin/haproxy-master
1218 ? Ss 0:00 /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid -Ds
1219 ? Ss 0:00 /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid -Ds
1220 ? Ss 0:00 /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid -Ds
1221 ? Ss 0:00 /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid -Ds
1393 pts/0 S+ 0:00 grep --color=auto ha
ubuntu@ip-172-31-1-115:~$ cat /proc/1217/limits
Limit Soft Limit Hard Limit Units
Max cpu time unlimited unlimited seconds
Max file size unlimited unlimited bytes
Max data size unlimited unlimited bytes
Max stack size 8388608 unlimited bytes
Max core file size 0 unlimited bytes
Max resident set unlimited unlimited bytes
Max processes 29852 29852 processes
Max open files 300035 300035 files
Max locked memory 65536 65536 bytes
Max address space unlimited unlimited bytes
Max file locks unlimited unlimited locks
Max pending signals 29852 29852 signals
Max msgqueue size 819200 819200 bytes
Max nice priority 0 0
Max realtime priority 0 0
Max realtime timeout unlimited unlimited us
Вы не упоминаете, что является ограничивающим фактором. Сначала вы работаете на общих виртуальных машинах, поэтому только провайдер хостинга знает, предоставляют ли они вам реальный процессор или нет. Во-вторых, возможно, вы загружаете ЦП на максимум, если напрягаете SSL. 11 тыс. Запросов / с может более или менее соответствовать тому, что можно ожидать от возобновленных соединений TLS на умеренной машине. В этом случае вы увидите, что haproxy использует 100% ЦП, в основном в пользовательском пространстве (обычно 60% пользователь / 40% sys). Если вы используете 11k RSA2048, поздравляю, это огромное количество! Если вы делаете это на чистых соединениях, он низкий, но может быть полностью вызван средой виртуальной машины. Если используется поддерживающее соединение, оно действительно слишком мало и даже может быть вызвано огромной задержкой в сети (что также характерно для виртуальных машин с чрезмерным резервированием).