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

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

Связанные:

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

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

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

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

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

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

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

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

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

Создайте свой сценарий

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

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

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

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

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

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

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

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

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

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

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

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

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

• JMeter (Веб, LDAP)
• Apache Benchmark (Веб)
• Grinder (Веб)
• httperf (Веб)
• WCAT (Веб)
• Нагрузочное тестирование Visual Studio (Веб)
• 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 в top, который использует больше всего памяти, добавьте немного для надежности, а затем разделите первое число (максимальное количество памяти, которое вы хотите, чтобы Apache использовал) на это новое число.
• Число, которое вы получите, должно быть вашими переменными MaxClients и ServerLimit.

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

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