Я пытаюсь настроить HAProxy для балансировки нагрузки для созданного мной настраиваемого веб-сервера. Прямо сейчас я замечаю увеличивающуюся задержку с HAProxy по мере увеличения размера возвращаемого сообщения. Например, я провел четыре разных теста, вот результаты:
Ответ 15кб через HAProxy:
Средн. время отклика: 0,34 секунды
Скорость транзакции: 763 транзакции / сек.
Пропускная способность: 11,08 МБ / с
Ответ 2кб через HAProxy:
Средн. время отклика: 0,08 секунды
Скорость транзакции: 1171 транзакций / сек.
Пропускная способность: 2,51 МБ / с
Ответ 15кб прямо на сервер:
Средн. время отклика: 0,11 сек
Скорость транзакции: 1046 транзакций / сек.
пропускная способность: 15,20 МБ / с
Ответ 2кб напрямую на сервер:
Средн. Время отклика: 0,05 секунды
Скорость транзакции: 1158 транзакций / сек.
Пропускная способность: 2,48 МБ / с
Все транзакции представляют собой HTTP-запросы. Как видите, разница между временем отклика, когда отклик больше, гораздо больше, чем когда он меньше. Я понимаю, что при использовании HAProxy будет небольшая задержка. Не уверен, имеет ли это значение, но сам тест проводился с использованием осады. И во время теста за HAProxy был только один сервер (тот же, что использовался в тестах direct to server). Вот мой файл haproxy.config:
global
log 127.0.0.1 local0
log 127.0.0.1 local1 notice
maxconn 10000
user haproxy
group haproxy
daemon
#debug
defaults
log global
mode http
option httplog
option dontlognull
retries 3
option redispatch
option httpclose
maxconn 10000
contimeout 10000
clitimeout 50000
srvtimeout 50000
balance roundrobin
stats enable
stats uri /stats
listen lb1 10.1.10.26:80
maxconn 10000
server app1 10.1.10.200:8080 maxconn 5000
Я не смог найти в этом файле много вариантов, которые помогли бы решить мою проблему. Я слышал предложения, что мне, возможно, придется отрегулировать некоторые из моих настроек sysctl. Я не смог найти много информации по этому поводу, однако большая часть документации относится к Linux 2.4 и 2.6 по материалу sysctl, я использую 3.2 (сервер Ubuntu 12.04), который, кажется, автоматически настраивается, поэтому я не знаю, что мне следует или не должно меняться. Большинство изменений настроек, которые я пробовал, не влияли или не влияли на производительность.
Просто обратите внимание, это очень предварительный тест, и я надеюсь, что во время развертывания мой HAProxy сможет сбалансировать 10-20 тысяч запросов в секунду для многих серверов, поэтому, если кто-нибудь может предоставить информацию, которая поможет мне достичь этой цели, Это будет высоко ценится.
Большое спасибо за любую информацию, которую вы можете предоставить. И если вам потребуется дополнительная информация от меня, пожалуйста, дайте мне знать, я дам вам все, что смогу.
[Edit] По запросу haproxy -vv
HA-Proxy version 1.4.18 2011/09/16
Copyright 2000-2011 Willy Tarreau <w@1wt.eu>
Build options :
TARGET = linux26
CPU = generic
CC = gcc
CFLAGS = -O2 -g -fno-strict-aliasing
OPTIONS = USE_LINUX_SPLICE=1 USE_LINUX_TPROXY=1 USE_PCRE=1
Default settings :
maxconn = 2000, bufsize = 16384, maxrewrite = 8192, maxpollevents = 200
Encrypted password support via crypt(3): yes
Available polling systems :
sepoll : pref=400, test result OK
epoll : pref=300, test result OK
poll : pref=200, test result OK
select : pref=150, test result OK
Total: 4 (4 usable), will use sepoll.
Я думаю о нескольких моментах:
1) вы работаете в виртуализированной среде?
2) у вас на машине загружен nf_conntrack?
3) вы когда-либо загружали ЦП на какой-либо из задействованных машин?
4) используйте "option http-server-close" вместо "option httpclose", поскольку последний позволяет обеим сторонам закрыться сами по себе, что приводит к более длинным соединениям.
5) что вы видите в логах haproxy? Время будет разделено на несколько полей, что позволит вам проанализировать, на что оно потрачено.
6) если вы видите намного меньшее время в журналах haproxy, чем то, что есть на вашем тестовом компьютере, это означает, что задержка вызвана ожиданием SYN-пакетов в системном бэклоге (или, что еще хуже, повторной передачи), что может быть вызвано отсутствием настройки системы .
7) (менее важно), сообщая о проблеме со старой версией, вы должны сначала обновить ее до последних исправлений (1.4.22), чтобы увидеть, сохраняется ли проблема. Я не думаю, что то, что вы наблюдаете, соответствует какой-либо известной проблеме, но все же это общая идея.