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


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

Связанный:

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

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


108
2018-01-16 22:49


Источник




Ответы:


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

Долгий ответ заключается в том, что бенчмаркинг вашей конкретной рабочей нагрузки - это то, что вам нужно предпринять самостоятельно, потому что это немного похоже на вопрос: «Сколько времени занимает строка?».

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

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

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

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

Поместите свой сценарий на место

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Нажмите на магию Идти и следите, чтобы ваши веб-серверы таяли и падали.

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

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

Исправление

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

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

Чтобы уменьшить масштаб, получите больше серверов.

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

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

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

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

Промыть, повторить

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

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


116
2018-04-29 14:05



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


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

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

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

Такие вещи, как% CPU и IOPS, являются системными, поэтому вы используете их только тогда, когда планируете систему и измеряете ее в предварительном производстве, чтобы выступать в качестве «суррогата» за то, что вам нужно, время.


9
2018-04-21 22:32





Планирование мощностей - неприятный зверь. Это как наука, так и искусство (если определенно темная).

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

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

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

К счастью, есть такая книга: "Искусство планирования потенциала"


8





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

Настройка Apache с помощью Mod_Prefork

апаш возможно, является одним из доступных (если не самый) доступный веб-сервер. Он является открытым исходным кодом и по-прежнему активно поддерживается. Вы можете запускать его как в 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 (используя верхний).
  • Возьмите процесс Apache сверху, который использует большую часть памяти, добавьте немного к нему для хорошей меры, а затем разделите свой первый номер (максимальный объем памяти, который вы хотите использовать Apache) на этот новый номер.
  • Номер, который вы получите, должен быть вашим MaxClients & ServerLimit переменные.

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


5



использование памяти, основанная исключительно на верхней части, немного испорчено, пожалуйста, проверьте f.e. stackoverflow.com/questions/7880784/... кроме того, вы можете использовать сценарий python «ps_mem.py» вместо верхнего для использования памяти или даже использовать значения directy, присоединенные к процессу в / proc - Dennis Nolte
Весь ответ стоит из-за примечания, которое вы добавили: «Вы никогда не должны использовать готовые конфигурации Apache». Мы никогда не можем это подчеркнуть. - ezra-s


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


0