Нагрузочное тестирование для обслуживания конечных точек

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

Что такое нагрузочный тест?

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

Представьте себе: Сейчас 8:00 утра в будний день, и популярное кафе в центре города только что открывается. Аромат свежего кофе заполняет воздух. Бариста готов, машины прогрелись, и очередь клиентов, испытывающих недостаток в кофеине, уже формируется.

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

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

Теперь представьте, что вы пытаетесь измерить, сколько напитков кафе может предложить в минуту, прежде чем клиенты начинают уходить разочарованными. Это нагрузочное тестирование.

В этой аналогии:

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

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

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

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

Основные понятия и определения нагрузочного тестирования

В следующей таблице определены связанные понятия нагрузочного тестирования:

Требования к задержке

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

Как связаны RPS, задержка и параллелизм?

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

• Чем больше параллелизма, тем выше пропускная способность.
• Чем выше задержка, тем ниже пропускная способность.

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

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

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

Примеры сценариев нагрузочного теста

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

Сценарий 1. Простая настройка

В этой настройке один клиент отправляет запросы последовательно— он ожидает ответа, прежде чем выпустить следующий запрос. Так как общее время на каждый запрос — это сумма задержки выполнения модели и накладной задержки (40 мс + 10 мс), измеренная сквозная задержка составляет 50 мс.

• Число клиентов: 1
• Подготовленная одновременность: 1
• Дополнительная задержка: 10 мс
• Время выполнения модели 40 мс

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

Сценарий 2. Увеличение подготовленного параллелизма

В этом случае у вас есть двойная выделенная параллельность и единственный клиент, который выполняет запросы последовательно. Это означает, что общая задержка по-прежнему составляет 50 мс (40 мс + 10 мс), и система видит только 20 запросов в секунду (QPS).

• Число клиентов: 1
• Выделенная параллельность: 1 –> 2
• Дополнительная задержка: 10 мс
• Время выполнения модели 40 мс

Сценарий 3. Добавление другого клиента в систему.

Теперь у вас есть два клиента, выполняющих запросы к конечной точке с двумя подготовленными параллелизмом. В этом случае запрос каждого клиента может быть независимо обработан конечной точкой одновременно (при условии идеальной балансировки нагрузки). Таким образом, в то время как общая задержка по-прежнему составляет 50 мс (40 мс + 10 мс), система наблюдает 40 запросов в секунду, так как каждый клиент отправляет 20 qps.

• Число клиентов: 1 –> 2
• Настроенная конкурентность: 2
• Дополнительная задержка: 10 мс
• Время выполнения модели 40 мс

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

Сценарий 4: Давайте уменьшим выделенную параллельность

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

• Число клиентов: 2
• Подготовленная конкуренция: 2 –> 1
• Дополнительная задержка: 10 мс
• Время выполнения модели: 40 мс

Здесь есть два клиента, выполняющих запросы одновременно. Однако конечная точка может обрабатывать только один запрос за раз. Это заставляет второй запрос ждать до обработки первого запроса. Ожидание или, более правильно, постановка второго запроса в очередь может отрицательно повлиять на время отклика системы. Если сервер разрешает очередь (включена по умолчанию в Службе моделей Databricks), второй клиент видит задержку в 90 мс: 10 мс (сетевая нагрузка) + 40 мс (время ожидания очереди) + 40 мс (время выполнения модели). Это значительно хуже, чем 50 мс, которые наблюдали раньше.