У нас есть установка, которая выглядит так:
nginx-> haproxy-> серверы приложений
Мы завершаем SSL с помощью nginx, и он стоит перед всем. Во время пикового времени загрузки производительность падает примерно вдвое. Запросы, которые обычно занимают 400 мс, занимают 800 мс. Это занимает больше времени для всего Интернета.
Проблема в том, что у меня нет абсолютно никаких признаков замедления в моих журналах и графиках. New Relic показывает, что все серверы приложений отвечают правильно, без изменения скорости. Nginx и haproxy ничего не показывают в своих логах о замедлении запросов, но мы замедляемся. Несмотря на то, что nginx показал, что конкретный отслеживаемый мной запрос занимает 17 мсек через весь стек, на его свертывание во время пиковой нагрузки на прошлой неделе ушло 1,5 секунды.
Итак, у меня остается два варианта: 1) Проблемы с сетью - у меня осталось более чем достаточно трубы, согласно графикам от маршрутизатора. Я использую только 400 Мбит / с из порта 1 Гбит / с, и нет ошибок в ifconfig, на коммутаторе или маршрутизаторах. Однако SoftLayer управляет этим оборудованием, поэтому я не могу проверить это лично. Я полагаю, это может быть на нашей стороне из-за ядра, поэтому я публикую свои значения sysctl ниже:
2) nginx задерживает запрос и либо не регистрирует его, либо я не регистрирую то, что нужно. Возможно ли, что запросы помещаются в очередь из-за того, что рабочие более заняты, и на них не так быстро реагируют? Если это действительно происходит, что я могу войти в nginx, кроме $ request_time, поскольку это вообще не показывает замедления. И, если это возможно, что запросы на самом деле занимают больше времени, чем указывает $ request_time, как мне настроить конфигурацию, чтобы ускорить процесс?
Sysctl
net.ipv4.tcp_syncookies = 0
net.ipv4.tcp_synack_retries = 2
net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.tcp_fin_timeout = 3
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 16777216 16777216 16777216
net.ipv4.tcp_wmem = 16777216 16777216 16777216
net.ipv4.tcp_max_tw_buckets = 16777216
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_max_syn_backlog = 262144
net.core.somaxconn = 262144
net.core.netdev_max_backlog = 15000
net.core.netdev_budget = 8196
net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.ip_nonlocal_bind = 1
Применимая конфигурация nginx
user www-data;
worker_processes 20;
worker_rlimit_nofile 500000;
error_log /var/log/nginx/error.log;
pid /var/run/nginx.pid;
events {
use epoll;
multi_accept off;
accept_mutex off;
worker_connections 65536;
}
Вы можете добавить время ожидания в очереди к новым реликтовым графам:
в конфигурации nginx на вашем SSL-терминаторе добавьте в серверный блок:
set $msecstart "${msec}000";
if ($msecstart ~ "^(.*)\.(.*)") {set $msecout "t=$1$2";}
proxy_set_header X-Request-Start $msecout;
Таким образом, заголовок X-Request-Start будет содержать время в микросекундах, и когда этот запрос попадет к агенту newrelic, он обновит графики. Убедитесь, что время хорошо синхронизировано как на балансировочном, так и на внутреннем серверах.
пс. 000 необходим, потому что $ msec в nginx находится в МИЛЛИСекундах, а агент newrelic ожидает данные в МИКРОсекундах.
Если вы возьмете максимальное количество одновременных подключений в часы пик и умножите это значение на 1,5, можете ли вы убедиться, что пул подключений вашего балансировщика нагрузки и серверов приложений не исчерпан? вы отслеживаете время ответа app-server- / ha-proxy? Можете ли вы убедиться, что проблема не в ваших серверах приложений?