Я настроил nginx в качестве балансировщика нагрузки, который выполняет обратные прокси-запросы к двум серверам Apache. Я проверил настройку с помощью ab и получаю примерно 35 запросов в секунду с запросами, распределенными между двумя внутренними серверами (без использования ip_hash). Меня сбивает с толку то, что если я запрашиваю любой из внутренних серверов напрямую через ab, я получаю около 50 запросов в секунду.
Я экспериментировал с рядом различных значений в ab, наиболее распространенным из которых является 1000 запросов при 100 одновременных подключениях.
Любая идея, почему трафик, распределенный между двумя серверами, приведет к меньшему количеству запросов в секунду, чем при прямом попадании на них?
Дополнительная информация:
Я экспериментировал со значениями worker_processes от 1 до 8, worker_connections между 1024 и 8092, а также пробовал поддерживать активность от 0 до 65.
Моя основная конфигурация в настоящее время выглядит так:
user www-data;
worker_processes 1;
error_log /var/log/nginx/error.log;
pid /var/run/nginx.pid;
worker_rlimit_nofile 8192;
events {
worker_connections 2048;
use epoll;
}
http {
include /etc/nginx/mime.types;
sendfile on;
keepalive_timeout 0;
tcp_nodelay on;
gzip on;
gzip_disable "MSIE [1-6]\.(?!.*SV1)";
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
}
У меня есть один виртуальный хост (на доступных сайтах), который перенаправляет все, что находится под / на 2 бэкэнда по локальной сети.
Параллелизм был моей первой мыслью, поскольку параллелизм по умолчанию в ab равен единице, а добавление балансировщика нагрузки всегда увеличивает задержку запроса, но вы упомянули, что устанавливаете параллелизм на 100, поэтому это не должно быть причиной.
Обратный прокси-сервер, вероятно, будет добавлять заголовок к каждому запросу. Это делает ответы немного больше при использовании nginx, чем при его отсутствии. Вероятно, незаметное изменение, если вы используете это во внутренней гигабитной сети, но если вы запускаете это из своего офиса или дома, и особенно если вы используете небольшой файл для этого теста, дополнительные данные могут вызвать измеримую разницу. . Конечно, небольшие файлы - это нормальное явление в Интернете, поэтому небольшие файлы могут быть более реалистичным тестом.
Кэширование также может иметь значение для последующих запусков в зависимости от того, как выполняется ваш тест. Это сделает вашу первую пробежку медленнее, чем все последующие пробежки. Это еще больше усугубляется при балансировке нагрузки, потому что требуется в два раза больше кешей для разогрева. Если вы сначала протестировали nginx, это могло вызвать разницу. Вы можете смягчить это, отключив кеширование или проигнорировав первый запуск, который вы делаете. Получить все кеши довольно сложно, а некоторые могут даже не находиться под вашим контролем. Я бы предпочел метод игнорирования первого запуска. Вы упомянули, что выполнили несколько запусков с разными значениями, но что вам нужно сделать, чтобы избежать неточностей, связанных с кешем, - это запустить точно так же выполнить тест два или более раз подряд и игнорировать первый прогон.
Еще одна вещь, которая может вызвать такое поведение, - это блокировка где-то еще в системе. Под «блокировкой» я подразумеваю ресурс, который может использовать только один из веб-серверов одновременно. Примером этого может быть сохранение сеансов PHP в таблице MyISAM в вашей базе данных. Каждый запрос к странице PHP будет выполнять либо запрос на чтение этой таблицы для поиска сеанса, либо запрос на запись для создания нового сеанса. Поскольку таблицы MyISAM имеют блокировку на уровне таблицы, только один из ваших веб-серверов может использовать эту таблицу в любой момент времени, а поскольку каждая страница должна будет использовать эту таблицу, это может полностью свести на нет преимущество наличия двух веб-серверов. Чем быстрее остальная часть вашей системы, тем больший относительный эффект будет иметь блокировка. Это также не обязательно должна быть база данных, это может быть общий веб-корневой каталог в SAN или NAS, поэтому даже статические файлы не защищены от подобных проблем. Вы не упомянули какие-либо другие системы в своем первоначальном вопросе, но эта проблема, скорее всего, появится по мере роста вашей системы.
И, наконец, немного (превратилось в довольно много) общих советов по тестированию производительности. Причина, по которой вы получаете определенную скорость (или количество запросов в секунду для такого рода тестов), всегда связана с одним узким местом. Тест Apache будет просто продолжать запрашивать как можно быстрее, пока какой-то ресурс не будет использован на 100%. Этим ресурсом могут быть ЦП на ваших веб-серверах или ЦП обратного прокси-сервера. Однако это маловероятно. Доступ к диску и пропускная способность сети (внутренняя и внешняя) обычно являются первыми узкими местами, с которыми вы сталкиваетесь, задолго до того, как скорость процессора становится проблемой. Даже если вы видите, что ресурс используется на 90%, это не узкое место. Где-то на 100% будет еще один, который не даст этому подняться выше 90%. Тот, что на 100%, может быть в другой системе, и это может быть не ваша система. Это может быть сеть, а это значит конкретное устройство например, коммутатор, сетевая карта или даже кабели, являющиеся частью сети.
Чтобы найти истинное «бутылочное горлышко», вы должны начать с некоторого значения, которое вы можете измерить (скажем, количества активных рабочих процессов nginx в настоящее время), и спросить: «Почему это не повышается?» Если он достиг максимального значения, значит, вы нашли свое узкое место. Если нет, то следующее место, куда вам следует обратить внимание, - это связанный запрос. Идете ли вы вверх по течению или вниз по течению, - это вопрос интуиции. Далее, nginx будет запрашивать сетевые слоты для передачи запросов Apache. Спросите себя, максимально ли количество открытых сетевых подключений. Затем пропускная способность сетевой карты. Затем пропускная способность сети. Затем пропускная способность NIC машины Apache. Вы можете пропустить некоторые из этих шагов, если ответ очевиден, но не пытайтесь наугад угадывать свой путь в системе. Сделайте свой квест упорядоченным и логичным.
Иногда узкое место, с которым вы сталкиваетесь, будет на компьютере, на котором вы работаете. Когда это происходит, тест теряет смысл. Все, что вы проверили, - это скорость машины или сети, на которой вы работаете. Вы получите такой же результат при тестировании Google, как и ваш сайт. Чтобы убедиться, что у вас есть значимый тест, вы должны найти узкое место во время выполнения теста. (Или, по крайней мере, убедитесь, что его нет на тестовой машине.) Чтобы улучшить тесты вашего сайта, необходимо найти узкое место в системе и расширить его, и это проще всего сделать во время выполнения теста.
Тестирование такой большой системы, как вы, означает, что количество мест, где может скрываться узкое место, довольно велико. Иногда это может помочь сузить тест до нескольких частей системы. Вырезание nginx и переход на Apache - один из примеров этого, а запуск вашего теста в той же сети, что и веб-серверы, - другой. Но вы можете пойти дальше и протестировать отдельные компоненты, такие как задержка и пропускная способность диска, сети и ОЗУ.
К сожалению, не все ресурсы имеют удобные процентные данные, сообщаемые так же, как использование ЦП и ОЗУ. Например, при записи большого файла на диск вы можете получить 40 МБ / с, но при одновременной записи большого количества маленьких файлов и их обратном чтении (например, сеансы PHP, хранящиеся на диске) вы можете получить 10 МБ / с. Чтобы определить истинный размер ресурса, вы должны запустить тесты производительности для каждой части вашей системы индивидуально. Не думайте, что вы получите скорость 1000 Мбит / с по внутренней сети только потому, что у вас есть гигабитный коммутатор. Заголовки IP, TCP и уровня приложения, такие как заголовки NFS, могут снизить этот тест, как и более медленные сетевые адаптеры и кабели. Аппаратные ошибки также могут повлиять на все виды тестов, пока оборудование все еще функционирует, но с меньшими показателями, чем указано производителем.
Узкое место может быть на машине nginx. Если это так, то причина того, что решение с балансировкой нагрузки работает медленнее, чем прямой одиночный сервер, должна быть очевидна. На этом этапе было бы полезно последовать некоторым предложениям rmalayter. Пока вы не узнаете, где находится узкое место, вы просто предполагаете, и мы тоже. Если узкое место в другом месте, вам, вероятно, следует найти его, а затем вернуться сюда и поискать или задать более конкретный вопрос.
Насколько велик содержимое файла, с которым вы тестируете?
Повернуть уровень ведения журнала в nginx, чтобы «предупредить», и проверьте error.log. Скорее всего, вы увидите предупреждения о записи проксированного содержимого во временные файлы на диске. Подозреваю, тебе нужно увеличить proxy_buffers количество / размер. Или полностью отключите буферизацию прокси. Значения по умолчанию для nginx слишком низкие, чтобы их можно было использовать для любого разумного современного контента.
С аналогичной конфигурацией я вижу 3700 запросов в секунду для статического html-файла 57 КБ, поступающего из двух внутренних ящиков IIS. Все это однопроцессорные виртуальные машины с 2 ГБ оперативной памяти. У меня proxy_buffers установлен как «proxy_buffers 32 16k;». Очевидно, что если вы видите только 50 запросов в секунду с Apache, вы тестируете динамическую страницу, верно?