Как вы проводите нагрузочное тестирование и планирование емкости для веб-сайтов?

Это канонический вопрос о планировании ёмкости для веб-сайтов.

Сопутствующие:

• Вы можете помочь мне с планированием ёмкости?
• Как вы тестируете нагрузку и планируете ёмкость для баз данных?

Какие рекомендованные инструменты и методы планирования ёмкости для веб-сайтов и веб-приложений?

Пожалуйста, не стесняйтесь описывать различные инструменты и методы для различных веб-серверов, фреймворков и т.д., а также лучшие практики, которые относятся к веб-серверам в общем.

Краткий ответ: Никто не может ответить на этот вопрос, кроме вас.

Длинный ответ заключается в том, что оценка вашей конкретной нагрузки — это то, что вам нужно сделать самостоятельно, потому что это немного похоже на вопрос “Насколько длинен кусок верёвки?”.

Простой одностраничный статичный сайт можно развернуть на Pentium Pro 150 и при этом обслуживать тысячи показов каждый день.

Основной подход, который вам нужно использовать для ответа на этот вопрос, — это попробовать и посмотреть, что произойдет. Существует множество инструментов, которые вы можете использовать, чтобы искусственно нагрузить вашу систему и увидеть, где она начинает давать сбой.

Краткий обзор:

• Установите ваш сценарий
• Добавьте мониторинг
• Добавьте трафик
• Оцените результаты
• Исправьте на основе результатов
• Повторите, пока не достигнете удовлетворительных результатов

Установите ваш сценарий

В общем, для тестирования нагрузки вам нужно что-то, с чем можно тестировать. Настройте среду для тестирования. Это должно быть близким к вашему производственному оборудованию, если это возможно, в противном случае вам придется экстраполировать ваши данные.

Настройте ваши серверы, аккаунты, веб-сайты, пропускную способность и т.д. Даже если вы сделаете это на виртуальных машинах, это нормально, лишь бы вы были готовы масштабировать ваши результаты.

Итак, я собираюсь настроить виртуальную машину средней мощности (два ядра, 512 МБ ОЗУ, 4 ГБ HDD) и установить мой любимый балансировщик нагрузки haproxy внутри Red Hat Linux на виртуальной машине.

У меня также будут два веб-сервера за балансировщиком нагрузки, которые я собираюсь использовать для стресстестирования балансировщика нагрузки. Эти два веб-сервера настроены идентично моим рабочим системам.

Добавьте мониторинг

Вам понадобятся некоторые метрики для мониторинга, поэтому я собираюсь измерить, сколько запросов проходит к моим веб-серверам, и сколько запросов я могу пропустить в секунду, прежде чем пользователи начнут получать время отклика более двух секунд.

Я также собираюсь отслеживать использование ОЗУ, ЦП и диска на экземпляре haproxy, чтобы убедиться, что балансировщик нагрузки может обрабатывать соединения.

Как это сделать, во многом зависит от ваших платформ и выходит за рамки этого ответа. Вам, возможно, нужно будет просмотреть журналы веб-сервера, запустить счетчики производительности или полагаться на возможности отчетности вашего инструмента стресстестирования.

Несколько вещей, которые вы всегда хотите мониторить:

• Использование ЦП
• Использование ОЗУ
• Использование диска
• Задержка диска
• Использование сети

Вы также можете рассмотреть возможность анализа взаимоблокировок SQL, времени доступа и т.д., в зависимости от того, что именно вы тестируете.

Добавьте трафик

Теперь дело становится интересным. Вам нужно смоделировать тестовую нагрузку. Есть множество инструментов, которые могут это сделать, с настраиваемыми параметрами:

• JMeter (Web, LDAP)
• Apache Benchmark (Web)
• Grinder (Web)
• httperf (Web)
• WCAT (Web)
• Тест нагрузки Visual Studio (Web)
• SQLIO (SQL Server)

Выберите число, любое число. Скажем, вы собираетесь посмотреть, как система реагирует на 10 000 запросов в минуту. Не имеет значения, какое число вы выберете, потому что вы будете повторять этот шаг много раз, изменяя это число вверх или вниз, чтобы увидеть, как система реагирует.

В идеале, вы должны распределить эти 10 000 запросов по нескольким клиентам/узлам тестирования нагрузки, чтобы один клиент не стал узким местом для запросов. Например, функция Удалённого тестирования JMeter предоставляет центральный интерфейс для запуска нескольких клиентов с управляющей машины Jmeter.

Нажмите на волшебную кнопку Начать и смотрите, как ваши веб-сервера “тают” и падают.

Оцените результаты

Теперь вам нужно вернуться к метрикам, которые вы собрали на этапе 2. Вы видите, что при 10 000 одновременных соединениях ваш экземпляр haproxy едва ли начинает потеть, но время отклика с двумя веб-серверами превышает пять секунд. Это не хорошо – помните, ваше время отклика стремится к двум секундам. Так что нам нужно внести некоторые изменения.

Исправления

Теперь вам нужно ускорить ваш сайт более чем в два раза. Вы знаете, что вам нужно либо масштабироваться вверх, либо расширяться.

Чтобы масштабироваться вверх, получите более мощные веб-серверы, больше ОЗУ, более быстрые диски.

Чтобы расшириться, добавьте больше серверов.

Используйте ваши метрики из этапа 2 и тестирования, чтобы принять это решение. Например, если вы увидели, что задержка диска была огромной во время тестирования, вы знаете, что нужно масштабироваться вверх и получить более быстрые жесткие диски.

Если вы увидели, что процессор работал на 100% во время теста, возможно, вам нужно расшириться, добавив дополнительные веб-серверы, чтобы снизить нагрузку на существующие серверы.

Нет универсального правильного или неправильного ответа, есть только то, что правильно для вас. Попробуйте масштабироваться вверх, и если это не сработает, расширьтесь. Или нет, это ваше решение и немного креативного мышления.

Предположим, что мы собираемся расширяться. Итак, я решаю клонировать мои два веб-сервера (это виртуальные машины), и теперь у меня четыре веб-сервера.

Повторите

Начните заново с Шага 3. Если вы обнаружите, что всё не идет, как вы ожидали (например, мы удвоили количество веб-серверов, но время отклика все еще больше двух секунд), то ищите другие узкие места. Например, вы удвоили количество веб-серверов, но всё еще имеете плохой сервер базы данных. Или вы клонировали больше виртуальных машин, но поскольку они находятся на одном физическом хосте, вы только увеличили конкуренцию за ресурсы сервера.

Затем вы можете использовать эту процедуру для тестирования других частей системы. Вместо того чтобы обращаться к балансировщику нагрузки, попробуйте загрузить веб-сервер напрямую, или SQL сервер с помощью инструмента стресстестирования SQL.

Планирование ёмкости начинается с измерений, в данном случае времени отклика по сравнению с нагрузкой. Как только вы узнаете, насколько программы замедляются под нагрузкой, что НЕ является линейной функцией, вы можете выбрать целевое время отклика, а затем выяснить, какие ресурсы потребуются, чтобы достичь этой цели при заданной нагрузке.

Измерение производительности всегда производится с единицами времени, поскольку

• это то, что волнует пользователей
• их можно масштабировать вверх и вниз

Такие вещи, как % ЦП и IOPS, являются специфичными для системы, поэтому вы используете их только тогда, когда спланировали систему и измерили её в преддодактовом состоянии, чтобы служить “заменителем” для того, что вам действительно важно — времени.

Тем не менее, высокая загрузка ЦП или ввода/вывода обычно указывает на плохую индексацию и/или плохую формулировку запросов. Используйте “slowlog”, чтобы отслеживать, какие запросы являются ‘хуже всего’.

Планирование ёмкости — это проблемная задача. Это как наука, так и искусство (определённо мрачное).

В лучшем случае вы принимаете обоснованные решения и удача сопутствует вам, так что реальность соответствует вашим предположениям. Если ваши предположения о потребностях в ёмкости совпадают с реальностью, вы выглядите как мистический йог. К сожалению, если ваши предположения превышают реальность, вам будет казаться, что вы превысили лимит и переплатили. Более печально, если ваши предположения ниже конечной реальности (или каким-либо образом неверные), вам будет не хватать необходимой ёмкости, и вам придётся поспешно искать способы смягчить неудачи вашей перегруженной инфраструктуры, что сделает вас похожим на человека, которому не хватает компетенции.

Никакого давления…

К сожалению, тёмное искусство планирования ёмкости — это больше, чем можно разумно уместить в один ответ на Server Fault; на самом деле, это тема, достойная книг.

К счастью, есть такая книга: “Искусство планирования ёмкости“.

Чтобы дополнить пост Марка Хендерсона, я пишу это конкретно для Apache. Чтобы повторить то, что он сказал: “Краткий ответ: Никто не может ответить на этот вопрос, кроме вас.” Текст этого ответа заимствован в значительной степени из моего ответа на похожий вопрос о производительности сайта на Drupal.

Настройка Apache с Mod_Prefork

Apache считается одним из (если не самым) популярных веб-серверов. Он является открытым источником и по-прежнему активно поддерживается. Вы можете запускать его как на Linux, так и на Windows, но он более популярен в мире Linux/Unix.

Вы никогда не должны использовать стандартную конфигурацию Apache. Вам всегда нужно настраивать Apache под ваш сайт. Главный файл конфигурации Apache на CentOS находится по пути /etc/httpd/conf/httpd.conf, а главный файл конфигурации Apache на системах Ubuntu обычно находится по пути /etc/apache2/apache2.conf. Дополнительные конфигурационные файлы используются для таких вещей, как виртуальные хосты.

Как и многое другое программное обеспечение, Apache создан для того, чтобы быть гибким и настроенным в соответствии с потребностями конкретного веб-сайта. Есть разные модули многопоточности, которые Apache можно настроить для работы с сетевым портом и обработки запросов.

В большинстве случаев при установке Apache по умолчанию на серверах CentOS и Ubuntu используется MPM “mod_prefork“. Если вы используете mod_prefork (если не уверены, то это более вероятно, но только вы можете это подтвердить), вот основы настройки:

• Определите максимальное количество памяти, которое вы хотите, чтобы Apache мог использовать.
• Тщательно тестируйте ваш веб-сайт и определите, сколько памяти использует каждый процесс Apache (используя top).
• Возьмите процесс Apache, который использует больше всего памяти, добавьте немного для надежности, а затем разделите ваше первое число (максимальное количество памяти, которое вы хотите, чтобы Apache использовал) на это новое число.
• Число, которое вы получите, должно стать вашими переменными MaxClients и ServerLimit.

Это определенно не окончательный ответ. Настройка вашего сервера Apache требует времени и опыта, чтобы сделать это правильно.

Также я бы посоветовал поговорить с архитекторами и инженерами, которые разрабатывали/строили приложения, чтобы попытаться выявить узкие места, единичные точки отказа и ограничения по лицензиям.