Вступление
Поскольку веб-сайты и веб-приложения становятся все более многофункциональными и сложными, производительность становится главной проблемой как для разработчиков, так и для пользователей. На странице studies, показывающей, что более быстрые сайты приводят к более активному участию пользователей, увеличению продаж и увеличению трафика, важно обратить внимание на то, как быстро вы можете доставить свой сайт своим пользователям и отобразить его в их браузер.
Общим термином для этой области знаний является _ оптимизация веб-производительности_, и за последние несколько лет было разработано много лучших практик, методов и технологий для улучшения работы в Интернете. Многие из этих методов направлены на уменьшение размера загрузки веб-страниц, оптимизацию JavaScript и ограничение количества отдельных HTTP-запросов, в которых нуждается страница.
В этой статье мы поговорим о другой стороне производительности сети: как быстро ваш сервер может отвечать на запросы вашего пользователя? Мы рассмотрим общую картину нагрузочного тестирования, рассмотрим план по поиску максимальной практической скорости отклика вашего сервера и обсудим некоторое программное обеспечение с открытым исходным кодом для нагрузочного тестирования.
глоссарий
Прежде чем мы начнем, давайте уточним некоторые соответствующие термины и понятия:
-
* Задержка * - это показатель * того, насколько быстро * сервер отвечает на запросы от клиента. Обычно измеряется в миллисекундах (мс), задержка часто упоминается как * время отклика *. Более низкие числа указывают на более быстрые ответы. Задержка измеряется на стороне клиента с момента отправки запроса до получения ответа. Сетевые издержки включены в этот номер.
-
* Пропускная способность * - это * количество запросов *, которые сервер может обработать в течение определенного промежутка времени, обычно сообщаемых как * запросов в секунду *
-
* Percentile * - это способ группировки результатов по их процентам от всей выборки. Если ваше время ответа 50-го процентиля составляет 100 мс, это означает, что 50% запросов были возвращены за 100 мс или меньше. На графике ниже показано, почему полезно смотреть на ваши измерения по процентилям: + image: https: //assets.digitalocean.com/articles/load-testing/p99.png [Пример графика задержки против время, показывающее большой всплеск в 99-м процентиле] + На графике выше показана задержка веб-сервера за определенный период времени. Несмотря на то, что среднее (среднее) время отклика довольно стабильно, в линии 99-го процентиля наблюдается большой всплеск. Это означает, что 1% запросов наших пользователей выполнялись даже хуже, чем это измерение 99-го процентиля, тогда как среднее значение оставалось относительно стабильным. По этой причине стоит посмотреть на процентили, чтобы получить более точное представление о том, что на самом деле испытывают ваши пользователи.
Основы нагрузочного тестирования
Нагрузочное тестирование - это практика отправки имитированного HTTP-трафика на сервер для измерения производительности и ответа на некоторые важные вопросы, такие как:
-
Достаточно ли ресурсов на сервере (процессор, память и т. Д.) Для обработки ожидаемой нагрузки?
-
Сервер отвечает достаточно быстро, чтобы обеспечить хороший пользовательский опыт?
-
Наше приложение работает эффективно?
-
Нужно ли расширять серверное оборудование или масштабировать до нескольких серверов?
-
Существуют ли какие-либо страницы или вызовы API, которые особенно ресурсоемки?
Нагрузочное тестирование выполняется путем запуска программного обеспечения нагрузочного тестирования на одной машине (или кластере машин) для генерации большого количества запросов к веб-серверу на второй машине (или другой более сложной инфраструктуре веб-обслуживания). Существует много таких инструментов, и мы рассмотрим некоторые конкретные программы позже. Сейчас мы обсудим нагрузочное тестирование в терминах, которые будут актуальны независимо от того, какое программное обеспечение вы выберете.
Обычное использование программного обеспечения для нагрузочного тестирования - это поиск * максимальных запросов в секунду *, которые может обработать сервер. Это делается путем отправки на сервер как можно большего количества запросов и проверки того, сколько он может вернуть успешно.
Это полезно в качестве первого шага к пониманию максимальной емкости вашего сервера, но не дает нам большой информации о задержке и фактической ежедневной производительности, с которой столкнутся ваши пользователи. Сильно загруженный сервер может возвращать тысячу ответов в секунду, но если каждый ответ занимает десять секунд, ваши пользователи, скорее всего, будут недовольны.
На приведенном ниже графике показано соотношение между пропускной способностью (откликов в секунду) и задержкой:
изображение: https: //assets.digitalocean.com/articles/load-testing/latency2.png [Пример графика задержки против запросы, показывающие положительную корреляцию между двумя]
Это всего лишь пример, и каждая настройка будет иметь уникальный профиль ответа, но общая тенденция заключается в том, что более высокая нагрузка (больше запросов в секунду) приводит к более высокой задержке. Чтобы получить более реальное представление о задержке нашего сервера при данной нагрузке, нам нужно будет протестировать несколько раз с разными частотами запросов. Не все программы нагрузочного тестирования способны на это, но позже мы обсудим + wrk2 +, инструмент для нагрузочного тестирования командной строки, который может выполнять эту функцию.
Теперь, когда у нас есть общее представление о нагрузочном тестировании, давайте обсудим конкретный план по исследованию производительности нашего сервера.
План нагрузочного тестирования
Есть несколько общих шагов, которые вы можете предпринять, чтобы понять, как ваш сервер и веб-приложение работают и реагируют на нагрузку. Во-первых, мы собираемся убедиться, что мы проверяем правильные системные ресурсы во время нагрузочного теста. Затем мы выясним абсолютное максимальное количество запросов в секунду, на которое способен наш сервер. Наконец, мы найдем максимальную пропускную способность, при которой задержка нашего сервера приведет к неприемлемой производительности для наших пользователей.
Шаг 1 - Мониторинг ресурсов
Наше программное обеспечение для нагрузочного тестирования предоставит нам информацию о запросах и задержке, но полезно отслеживать некоторые другие системные показатели, чтобы увидеть, не становится ли сервер ограниченным в ресурсах при работе с большими объемами трафика.
В основном мы заботимся о загрузке процессора и свободной памяти: наблюдение за ними в условиях высокой нагрузки поможет вам принимать более обоснованные решения о том, как масштабировать инфраструктуру и на чем сосредоточить усилия при разработке приложения.
Если вы уже настроили систему мониторинга (например, Prometheus или Graphite и CollectD) все готово. Если нет, войдите на свой веб-сервер через SSH и используйте следующие инструменты командной строки для мониторинга в режиме реального времени.
Чтобы проверить доступную память, вы можете использовать команду + free +. Объедините его с + watch +, чтобы периодически (каждые две секунды по умолчанию) обновлять вывод:
watch free -hФлаг + -h + указывает + free + выводить числа в удобочитаемом формате вместо байтов:
Output total used free shared buffers cached
Mem: 489M 261M 228M 352K 7.5M 213M
-/+ buffers/cache: 39M
Swap: 0B 0B 0BВыделенное число в выводе выше представляет свободную память после вычитания использования буфера и кэша. Более новые версии + free + изменили вывод:
Output total used free shared buff/cache available
Mem: 488M 182M 34M 14M 271M
Swap: 0B 0B 0BНовый столбец + available + вычисляется немного по-другому, но обычно представляет собой ту же метрику: память, доступная в настоящее время для использования приложениями.
Для мониторинга использования ЦП из командной строки, mpstat - это хорошая утилита, которая дает обновляемое представление об объеме свободных ресурсов ЦП. mpstat не устанавливается по умолчанию в Ubuntu. Вы можете установить его с помощью следующей команды:
sudo apt-get install sysstatКогда вы запускаете + mpstat +, вам нужно указать количество секунд, которое вы хотите между обновлениями:
mpstat 2Это выведет строку заголовка, а затем строку статистики каждые две секунды:
OutputLinux 4.4.0-66-generic (example-server) 08/21/2017 _x86_64_ (4 CPU)
08:06:26 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice
08:06:28 PM all 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
08:06:30 PM all 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00+% idle + показывает процент неиспользуемых ресурсов процессора. Причина, по которой мы смотрим, сколько * простаивает * вместо того, сколько * используется *, заключается в том, что загрузка ЦП часто делится на разные категории, такие как * пользовательский * ЦП и * системный * ЦП. Вместо того, чтобы сложить их на лету, мы смотрим на пустую сторону уравнения.
Теперь, когда мы можем наблюдать за ресурсами нашего сервера, давайте запустим тест начальной загрузки, чтобы определить максимальную скорость отклика нашего сервера.
Шаг 2 - Нахождение максимальной скорости отклика
Как упоминалось ранее, большинство программ для нагрузочного тестирования особенно хорошо подходит для определения максимальной скорости отклика вашего веб-сервера. Часто единственные параметры, которые вам нужно установить, - это желаемое concurrency и продолжительность теста.
Параллельность - это мера количества параллельных подключений к серверу. 100 является безопасным выбором по умолчанию для этого, но вы можете сделать более осознанный выбор, проверив настройки + MaxClients +, + MaxThreads + вашего веб-сервера или аналогичные настройки, чтобы определить, сколько одновременных соединений он может обработать.
В дополнение к настройке этих параметров вам нужно будет выбрать URL-адрес для теста. Если ваше программное обеспечение может обрабатывать только один URL-адрес за раз, стоит провести несколько тестов с несколькими различными URL-адресами, поскольку требования к обработке могут сильно различаться, например, между вашей домашней страницей и страницей продукта, для загрузки которой требуется несколько запросов к базе данных. ,
Кроме того, некоторые программы для нагрузочного тестирования позволяют указывать несколько URL-адресов для одновременного тестирования. Это хороший способ более точно симулировать трафик в реальном мире. Если у вас есть данные об использовании сайта (из аналитического программного обеспечения или журналов сервера), вы можете точно сопоставить свои тестовые URL-адреса с наблюдаемыми значениями.
Когда вы разобрались с URL или URL для тестирования, запустите нагрузочный тест. Убедитесь, что ваше программное обеспечение отправляет запросы как можно быстрее. Если вы используете программное обеспечение, которое требует от вас выбирать частоту запросов, выберите значение, которое почти наверняка будет слишком большим. Если ваша программа имеет настраиваемую задержку между запросами, уменьшите ее до нуля.
Вы должны увидеть потребление ресурсов процессора и памяти. Ваш процессор может простаивать до 0%, а клиент нагрузочного тестирования может получить некоторые ошибки подключения, так как ваш сервер пытается удовлетворить все запросы. Это нормально, так как мы выдвигаем сервер до предела.
Когда все закончится, ваше программное обеспечение будет выводить некоторую статистику, включая * количество запросов в секунду *. Также обратите внимание на * время отклика *: оно, вероятно, будет очень плохим, поскольку сервер должен был быть чрезмерно растянутым. Из-за этого число запросов в секунду не является хорошим показателем реальной максимальной пропускной способности вашего сервера, но является хорошей отправной точкой для дальнейшего изучения.
Затем мы перезвоним нагрузку и протестируем снова, чтобы получить больше информации о том, как работает наш сервер, когда он не установлен на абсолютном пределе.
Шаг 3 - Найти максимальную практическую пропускную способность
Для этого шага нам нужно использовать программное обеспечение для нагрузочного тестирования, которое может немного снизить нагрузку, чтобы протестировать производительность нашего сервера на разных уровнях пропускной способности. Некоторое программное обеспечение делает это, позволяя вам указывать задержку между каждым запросом, но это затрудняет определение точной пропускной способности.
К счастью, + wrk2 + позволяет вам указывать точное количество запросов в секунду. Он делает это, сначала выполняя несколько запросов на калибровку, чтобы точно рассчитать время.
Возьмите максимальную частоту запросов из предыдущего шага и сократите ее пополам. Запустите еще один тест с этой новой скоростью и отметьте время ответа. Это все еще в приемлемом диапазоне?
Если да, увеличьте скорость до максимума, тестируя по мере продвижения, пока задержка не достигнет максимального значения, которое вы определили как приемлемое. Это максимальная скорость ответа, которую ваш сервер может обработать, прежде чем ваши пользователи будут испытывать снижение производительности.
Далее мы рассмотрим некоторые доступные пакеты программного обеспечения с открытым исходным кодом, чтобы помочь нам реализовать наш план нагрузочного тестирования.
Программное обеспечение для нагрузочного тестирования
Существует множество пакетов программного обеспечения с открытым исходным кодом, доступных для нагрузочного тестирования. Кроме того, существует множество коммерческих служб, которые будут запускать инфраструктуру нагрузочного тестирования для вас и автоматически создавать графики и отчеты на основе данных испытаний. Эти сервисы могут быть хорошим выбором для предприятий, которым необходимо генерировать большой объем нагрузки для тестирования крупномасштабной инфраструктуры, так как большинство из них запускают кластеры машин для генерации гораздо большего количества запросов, чем один сервер.
Тем не менее, некоторые из инструментов с открытым исходным кодом также могут работать в режиме кластера. Давайте рассмотрим некоторые из наиболее популярных инструментов с открытым исходным кодом и кратко рассмотрим их возможности:
ab
ab (также известный как ApacheBench) - это простой однопоточный инструмент командной строки для бенчмаркинга HTTP-сервера. Хотя он изначально был распространен как часть HTTP-сервера Apache, вы можете использовать ab для тестирования любого HTTP или HTTPS-сервера.
Поскольку он однопоточный, ab не может использовать преимущества нескольких процессоров для отправки большого количества запросов. Это может быть ограничением, если вы пытаетесь полностью загрузить мощный веб-сервер.
Базовый вызов команды + ab + выглядит следующим образом:
ab -n 1000 -c 100Вы указываете количество запросов (+ -n +) и параллелизм (+ -c +), а затем даете ему один URL для извлечения. Вывод, приведенный ниже, содержит запросы в секунду, время запроса и список различных процентилей времени ответа:
Output. . .
Time per request: 1.361 [ms] (mean, across all concurrent requests)
Transfer rate: 60645.11 [Kbytes/sec] received
Percentage of the requests served within a certain time (ms)JMeter
JMeter - это мощное и многофункциональное приложение для нагрузочного тестирования и функционального тестирования от Apache Software Foundation. Функциональное тестирование означает, что JMeter также может тестировать, чтобы убедиться, что ваш сайт или приложение выдает правильные результаты.
JMeter имеет графический интерфейс Java для настройки Test Plan:
image: https: //assets.digitalocean.com/articles/load-testing/jmeter.png [Интерфейс JMeter по умолчанию]
Планы тестирования могут быть записаны с помощью веб-прокси JMeter для записи трафика и обычного браузера. Это позволяет вам тестировать трафик, более точно имитирующий реальное использование.
JMeter может выводить процентильную информацию в отчетах HTML и других форматах.
Siege
Siege - еще один инструмент для нагрузочного тестирования командной строки, похожий на ab, но с несколькими различными функциями. Siege является многопоточным, обеспечивая относительно высокую пропускную способность. Это также позволяет вам предоставить список из нескольких URL-адресов для тестирования под нагрузкой. Основной вызов следует:
siege -c 100 -t 30sДля этого требуется 100 одновременных запросов (+ -c 100 +) и тридцать секунд проверки (+ -t 30s +). Siege выводит среднее время ответа и частоту запросов:
Output. . .
Transactions: 5810 hits
Availability: 100.00 %
Elapsed time: 29.47 secs
Data transferred: 135.13 MB
Throughput: 4.59 MB/sec
Concurrency: 2.23
. . .Осада не дает никакой процентной разбивки для своей статистики задержек.
Locust
Locust - инструмент нагрузочного тестирования на основе Python с веб-интерфейсом в реальном времени для мониторинга результатов:
изображение: https: //assets.digitalocean.com/articles/load-testing/locust.png [страница с результатами теста с саранчой]
Вы пишете тестовые сценарии Locust в коде Python, предоставляя мощную конфигурацию, удобную для тех, кто уже знаком с языком.
Locust также можно запускать в распределенном режиме, где вы можете запустить кластер серверов Locust и обеспечить их скоординированную загрузку. Это облегчает нагрузочное тестирование мощной инфраструктуры веб-обслуживания.
Locust может предоставить подробную статистику и процентиль в загружаемых CSV-файлах.
wrk2
wrk2 - это многопоточный инструмент для нагрузочного тестирования командной строки, способный генерировать нагрузку с заданной частотой запросов. Он может предоставить подробную статистику задержки и может быть написан с помощью языка программирования Lua.
wrk2 вызывается командой + wrk + (это вилка оригинального + wrk +):
wrk -t4 -c100 -d30s -R100 --latencyВышеуказанные параметры указывают четыре потока (+ -t4 +, вы должны использовать количество ядер процессора на вашей машине), 100 одновременных запросов (+ -c100 +), тридцать второй период тестирования (+ -d30s +), и частота запросов 100 запросов в секунду (+ -R100 +). Наконец, мы запрашиваем подробный вывод задержки с помощью + - latency +:
Output. . .
Latency Distribution (HdrHistogram - Recorded Latency)
50.000% 5.79ms
75.000% 7.58ms
90.000% 10.19ms
99.000% 29.30ms
99.900% 30.69ms
99.990% 31.36ms
99.999% 31.36ms
100.000% 31.36ms
. . .Приведенный выше вывод является выдержкой - также выводятся более подробные процентили задержки.
Заключение
В этой статье мы рассмотрели некоторые термины и основные концепции нагрузочного тестирования, обошли план, чтобы найти максимальные практические запросы в секунду, наблюдали системные ресурсы для принятия будущих решений об оборудовании и усилиях по разработке, а также рассмотрели некоторые из доступных открытых исходных кодов. нагрузочное тестирование программного обеспечения.
После измерения производительности вашей инфраструктуры вы можете использовать эту информацию, чтобы попытаться улучшить время отклика и снизить нагрузку на сервер. Возможно, вы захотите увеличить аппаратное обеспечение вашего веб-сервера или использовать несколько серверов и балансировщик нагрузки. Вы можете попытаться отрегулировать конфигурацию своего веб-сервера, чтобы оптимизировать количество разрешенных подключений или количество используемых рабочих процессов или потоков. Вы также можете изучить кэширование часто используемых данных в памяти, чтобы уменьшить нагрузку на базу данных и время запроса.
Вы можете найти вышеупомянутые темы и многое другое по адресу our collection из * Оптимизация сервера * помеченных учебников.