Запуск Locust в распределенном режиме на функциях Azure - PullRequest
Новая
       29

Запуск Locust в распределенном режиме на функциях Azure

0 голосов
/ 15 мая 2018

Я создаю небольшую утилиту, которая упаковывает инструмент тестирования производительности Locust (https://locust.io/) и развертывает его на функциях Azure. Это просто забавный сторонний проект, чтобы освоить безумное увлечение сервером.

Вот репозиторий git: https://github.com/amanvirmundra/locust-serverless.

Теперь я думаю, что было бы здорово запустить тест на саранчу в распределенном режиме на архитектуре без сервера (план потребления функций Azure). Locust поддерживает распределенный режим, но ему нужны подчиненные устройстваобщаться с мастером, используя его IP. В этом проблема !!

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

Размышление вслух:

  1. Каким-то образом получить IP-адрес главной функции и передать его подчиненным функциям. Не уверен, что это возможно в функциях Azure, но некоторые люди нашли способполучить IP-адрес Azure функции с использованием библиотек .net. Моя версия Python, но я уверен, что это можно сделать с помощьюg .net, тогда будет и путь на Python.
  2. Создайте своего рода VPN и сопоставьте функцию частному IP.Не уверен, что такое сопоставление возможно в Azure.
  3. Некоторые сделали это, используя AWS Lambdas (https://github.com/FutureSharks/invokust). Спросите этого человека или попытайтесь понять код.

Нужен совет в выяснении того, что возможно в то же время, чтобы сохранить вещи без сервера. Открыты для идей и / или вкладов кода:)

Обновление

Это текущая настройка:

  1. Сеанс теста производительности запускается запросом http, который принимает количество запросов, базовый URL и no.одновременных пользователей для симуляции.
  2. Locustfile определяет настройку теста и оркестровку.
  3. Run.py запускает тесты.

То, что я хочу сделать сейчас, этоиметь мастер / подчиненную настройку (кластер) для массового тестирования производительности.

  • Я полагаю, что основная функция запускается HTTP-запросом с аналогичной полезной нагрузкой.
  • Мастер, в свою очередь, запускает рабов.
  • Когда подчиненные присоединяются к кластеру, начинается сеанс производительности.

1 Ответ

0 голосов
/ 15 мая 2018

То, что вы описываете, не похоже на хороший вариант использования функций Azure.

Предполагается, что следующие функции:

  • Инициируются событием
  • Короткая работа (максимум 10 минут)
  • Без состояния и эфемерно

Но, действительно, функции хороши для нагрузочного тестирования, но настройка должна отличаться:

  • Вы определяете триггер для своей функции (например, HTTP или концентратор событий)
  • Каждое выполнение функции выполняет заданное количество запросов, параллельно или последовательно, а затем завершает работу
  • Существуетгде-то оркестратор (например, просто консольное приложение), который отправляет «команды» (HTTP-вызов или событие) для запуска функции

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

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

Я думаю, что упомянутый пример на основе AWS Lambda просто вызывает Lambdas, он не настраивает лямбды master-client, говорящие друг с другом.

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

...