1. подготовка
2. Ваша настройка нагрузочного тестирования
3. Мудро выбирайте инструмент
4. JMeter
5. Wrk
6. Вегета
7. Инструменты SaaS
8. Blazemeter
9. Loader.io
10. Установление базовой линии
11. Первый забег

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

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

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

Мы можем сказать, что лучшая функция вашего API - это отличная производительность. И мы знаем, что единственный верный способ достичь цели - это тщательно выбирать ключевые метрики, итеративно измерять и настраивать вашу систему, пока не будут достигнуты поставленные цели. Для API процесс измерения и улучшения производительности - это нагрузочное или стресс-тестирование.

Эта статья будет посвящена описанию того, как успешно запустить нагрузочный тест на вашем API. Мы начнем с простого неизмеримого API и продолжим добавлять слой контроля доступа и убедимся, что все проверено в бою и готово к обработке рабочего трафика. Давайте тогда!

подготовка

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

В оставшейся части этой статьи мы будем использовать пример API во всех наших тестах. Это Node.js API для игры Карты против человечества. Он имеет три конечные точки:

• / вопрос - возвращает случайную черную карту
• / ответ - возвращает случайную белую карточку
• / pick - возвращает случайную пару вопросов и ответов

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

По этой причине вам следует начать с сбора данных об использовании вашего API. Вероятно, вы можете получить эти данные либо непосредственно из журналов вашего сервера API, либо из любого инструмента для повышения производительности приложений, который вы используете (например, New Relic). Перед запуском первых тестов вашего API вы должны иметь ответы на следующие вопросы:

• Средняя пропускная способность в запросах в секунду
• Пиковая пропускная способность (Какой самый большой трафик вы получаете за определенный период?)
• Распределение пропускной способности по конечной точке API (есть ли у вас конечная точка, которая получает значительно больше трафика, чем любая другая?)
• Распределение пропускной способности по пользователям (немногие генерируют большую часть трафика или оно распределено более равномерно?)

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

1. Генерация повторяющихся нагрузок
2. Имитация моделей трафика
3. Реальный трафик

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

Как только вы нашли этот максимум, вы можете начать думать о том, как сделать трафик, который вы генерируете, более реалистичным. Использование реального трафика - идеальный сценарий, хотя и не всегда осуществимый. Это может быть слишком сложно или просто займет слишком много времени, чтобы настроить его, поэтому мы предлагаем промежуточный шаг: изучение аналитики трафика и простое вероятностное моделирование. Например, если у вас есть API с 100 конечными точками, вы можете проверить использование за последний месяц и выяснить, что 80% трафика идет на 20 конечных точек, а верхние 3 конечных точки занимают 50% всего трафика. Затем вы можете создать список запросов, соответствующих этой вероятности, и направить его в свой инструмент нагрузочного тестирования. Это было бы относительно быстро, и в большинстве случаев это будет достаточно близко, чтобы показать любые проблемы, которые могут возникнуть у вас с реальным трафиком.

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

Ваша настройка нагрузочного тестирования

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

Если у вас уже есть среда подготовки к работе или песочница с вашим API, то все готово. Поскольку для этой статьи мы используем пример API, мы собираемся настроить его на экземпляре сервера AWS.

В нашем случае мы работаем с простым API, который не требует чтения с диска или хранения большого набора данных в памяти. Поэтому мы выберем экземпляр AWS, предназначенный для рабочей нагрузки, связанной с процессором. Мы пойдем с линуксом c4.large пример.

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

Далее мы также раскручиваем экземпляр, который будет выполнять инъекцию нагрузки. Это просто сервер, на котором запущена программа, которая будет имитировать пользователей нашего API путем многократной отправки запросов от нескольких одновременных подключений к нашему серверу API. Чем выше нагрузка, которую вам нужно смоделировать, тем мощнее будет этот сервер. Еще раз, это также будет нагрузка на процессор. Здесь мы выбрали c4.xlarge Экземпляр AWS с 4 виртуальными ядрами и оптимизированным процессором с 16 ЭКЮ ,

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

Мудро выбирайте инструмент

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

JMeter

Лидер пакета в осведомленности, вероятно, Apache JMeter , Это Java-приложение с открытым исходным кодом, ключевой особенностью которого является мощный и полный графический интерфейс, который вы используете для создания планов тестирования. План тестирования состоит из компонентов теста, которые определяют каждый элемент теста, таких как:

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

Плюсы:

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

Минусы:

• GUI имеет крутой кривой обучения. Он раздут с опциями, и есть много концепций, которые нужно выучить, прежде чем вы сможете запустить свой первый тест.
• При тестировании с высокими нагрузками рабочий процесс становится громоздким. Сначала вам нужно будет использовать графический интерфейс для создания плана тестирования XML. Затем запустите тестирование импорта этого плана с приложением в режиме без графического интерфейса, поскольку графический интерфейс требует слишком много ресурсов, необходимых для увеличения нагрузки. Вам также нужно будет запустить тест, следя за тем, чтобы все прослушиватели (компоненты, которые собирают данные и показывают измерения) были отключены, поскольку они тоже потребляют ресурсы. Наконец, вам нужно будет импортировать необработанные данные результатов в графический интерфейс, чтобы увидеть результаты.
• Если ваша цель - протестировать постоянную пропускную способность во времени (например, 1000 запросов в секунду в течение 60 секунд), будет трудно найти правильную комбинацию количества одновременных потоков во времени и таймеров между запросами, чтобы получить это устойчивое число.

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

Wrk

Wrk это инструмент, который очень похож на традиционный Apache Benchmark (который был впервые разработан как эталон для сервера Apache). По сравнению с JMeter, и wrk, и ab - радикально разные звери:

• Все настраивается и выполняется через инструмент командной строки
• Несколько, но мощных настроек, только необходимых для генерации нагрузки HTTP
• Высокая производительность

Тем не менее, wrk имеет несколько улучшений по сравнению с более традиционными ab, наиболее замечательными из которых являются:

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

С другой стороны, генерируемые отчеты по умолчанию ограничены как по содержанию, так и по формату (только текст, без графиков). Мы сочли wrk лучшим инструментом, когда ваша цель - определить максимальную нагрузку, которую может выдержать ваш API. Просто нет более быстрого инструмента для этой работы.

Вегета

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

Инструменты SaaS

Как вы видели до этого момента, выполнение простого нагрузочного теста требует некоторой подготовки к настройке среды. В последнее время появилось несколько продуктов, предлагающих инфраструктуру нагрузочного тестирования в качестве услуги. Мы попробовали два из них: Loader.io а также Blazemeter ,

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

Blazemeter

Этот продукт нацелен на ту же проблему, о которой мы упоминали при рассмотрении JMeter ранее: если вам нужно использовать его для высоких нагрузок, вам нужно будет создать планы тестирования из графического интерфейса, а затем загрузить эти планы на другом сервере, на котором работает JMeter в режиме без графического интерфейса , Blazemeter позволит вам загрузить план тестирования JMeter и запустить его из своей облачной инфраструктуры. К сожалению, для наших целей установлен бесплатный план на 50 одновременных пользователей, но мы обязательно вернемся к этому инструменту в будущем.

Loader.io

Простой и мощный сервис облачного нагрузочного тестирования от SendGrid , он имеет только нужные функции и приятные визуальные отчеты. Бесплатный план в Loader.io щедрый и обеспечивает пропускную способность до 10 000 запросов в секунду, что означает, что вы можете использовать его для запуска реального нагрузочного теста.

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

Установление базовой линии

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

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

Необходимо иметь некоторые инструменты на сервере API, чтобы мы могли отслеживать использование ресурсов во время тестов. Мы используем keymetrics.io вместе с отличным PM2 Модуль для этого.

Наше приложение Node.js работает очень просто HTTP-сервер , Node.js является однопоточным, но для того, чтобы использовать два ядра, доступные в экземпляре c4.large AWS, мы используем функцию кластеризации, которая PM2 включает в себя запустить два рабочих процесса приложения.

Поскольку наш API полностью не имеет состояния, было бы легко использовать модуль основного кластера , который фактически используется PM2 внутри, напрямую. Однако кластеризация через PM2 предоставляет несколько хороших команд быстрого вызова для запуска / остановки / перезагрузки приложения, а также отслеживает процессы.

Первый забег

Мы начнем с первого запуска теста с использованием Loader.io поверх нашего API. Это результаты 30-секундного теста со скоростью 10.000 запросов в секунду, что является максимальной пропускной способностью, которую Loader.io допускает в своем бесплатном плане.

Во время этого теста мы видим, что процессор сервера API достигает 100% мощности только несколько раз во время теста.

Это указывает на то, что наш API, вероятно, способен обрабатывать даже более высокую пропускную способность. Мы проверяем это с помощью второго теста, запустив wrk на нашем сервере загрузки инжектора. Цель состоит в том, чтобы довести наш сервер API до предела.

wrk -t 4 -c 1000 -d 60 - время ожидания - время ожидания 3 с HTTP: // апи-сервер / вопросы

И вот результаты одного из нескольких повторений этого теста:
Выполнение теста 1м @ HTTP: // апи-сервер / вопрос
темы и 1000 соединений
Статистика потока Avg Stdev Max +/- Stdev
Задержка 62,23 мс 30,85 мс 1,35 мкс 99,39%
Треб / сек 4.07k 357.61 5.27k 94.29%
Распределение задержки
50% 60,04 мс
75% 63,85 мс
90% 64,17 мс
99% 75,86мс
972482 запросов на 1,00 м, прочитано 189,89 МБ
Запросов / сек: 16206.04
Передача / сек: 3.16MB

Результаты показывают, что наша догадка подтвердилась: она достигла 16 206 запросов / сек, сохраняя при этом разумную задержку, при этом 99-й процентиль составлял всего 75,86 мс. Мы возьмем это за базовую максимальную пропускную способность, так как в этот раз мы увидели, как работает сервер API на максимальной мощности:

Мы только что увидели простой способ определить максимальную нагрузку на трафик, к которой готов ваш API, в то же время представив и обсудив некоторые инструменты, которые мы обнаружили в процессе.

связанные с

Похожие

Комментарии