Locust.io: Управление параметром запроса в секунду

Question

Я пытаюсь загрузить тестовый сервер моего API с помощью Locust.io в EC2 для вычисления оптимизированных экземпляров. Он предоставляет простой в настройке параметр для установки времени ожидания последовательного запроса и количество одновременных пользователей. Теоретически rps = Время ожиданияX#_users. Однако при тестировании это правило ломается для очень низких пороговых значений #_users (в моем эксперименте около 1200 пользователей). Переменные hatch_rate, #_of_slaves, в том числе в заходящего имел практически никакого влияния на RPS в распределенного тестирования.

Эксперимент Информация

Испытание было сделано на C3.4x AWS EC2 вычислительного узел (AMI изображение) с 16 виртуальных ЦП, с General SSD и 30GB RAM. Во время теста загрузка процессора достигала максимума до 60% (зависит от скорости штриховки, которая контролирует одновременные процессы, порожденные), в среднем до 30%.

Locust.io

установки: использует pyzmq, и настройку каждого ядра VCPU в качестве раба. Единая настройка запроса POST с телом запроса ~ 20 байтов и тело ответа ~ 25 байт. Частота отказов запросов: < 1%, среднее время отклика составляет 6 мс.

переменные: Время между последовательными запросами установлен в 450ms (мин: 100 мс и 1000 мс: макс), скорость люка в удобном 30 в секунду, а РПС измеряется путем изменения #_users.

РПС следующим уравнением, как предсказано для Шифрование до 1000 пользователей. Увеличение #_users после этого уменьшает отдачу с крышкой, достигаемой примерно у 1200 пользователей. #_users здесь не является независимой переменной, меняя время ожидания. также влияет на RPS. Однако изменение настройки эксперимента на экземпляр 32 ядер (пример c3.8x) или 56 ядер (в распределенной настройке) вообще не влияет на RPS.

Итак, каков способ управления RPS? Есть ли что-то очевидное, что я здесь отсутствует?

Answer 1

(один из авторов саранчи здесь)

Во-первых, почему вы хотите, чтобы контролировать RPS? Одной из основных идей, лежащих в основе Locust, является описание поведения пользователя и возможность генерации нагрузки (запросы в вашем случае). Вопрос Locust предназначен для ответа: сколько одновременных пользователей может поддерживать мое приложение?

Я знаю, что заманчиво пойти после определенного номера RPS, а иногда и «обманывать», стремясь к произвольному номеру RPS.

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

Распределенный режим рекомендуется для более крупных производственных установок, и большинство реальных нагрузочных тестов, которые я запускал, были на нескольких, но меньших экземплярах. Но не имеет значения, не выкидываете ли вы CPU. Вы уверены, что не насыщаете одно ядро ​​процессора? Не знаете, какую ОС вы используете, но если Linux, какова ваша стоимость загрузки?