Я пытался загрузить тестовый сервер API с помощью Locust.io на экземплярах, оптимизированных для вычислений EC2. Он предоставляет простой в настройке параметр для установки времени ожидания последовательного запроса и количества одновременных пользователей. Теоретически rps = время ожидания X #_users. Однако во время тестирования это правило не работает для очень низких пороговых значений #_users (в моем эксперименте около 1200 пользователей). Переменные hatch_rate, #_of_slaves, включая настройку распределенного теста, практически не повлияли на rps.
Информация об эксперименте
Тест проводился на вычислительном узле C3.4x AWS EC2 (образ AMI) с 16 виртуальными ЦП, твердотельным накопителем General и 30 ГБ ОЗУ. Во время теста загрузка ЦП достигла максимума 60% (зависит от скорости вывода, которая контролирует параллельные порождаемые процессы), в среднем оставаясь ниже 30%.
Locust.io
setup: использует pyzmq и настраивает каждое ядро vCPU как подчиненное устройство. Настройка одиночного запроса POST с телом запроса ~ 20 байтов и телом ответа ~ 25 байтов. Частота отказов запросов: ‹1%, при среднем времени ответа 6 мс.
переменные: время между последовательными запросами, установленное на 450 мс (мин: 100 мс и макс: 1000 мс), скорость вывода при удобных 30 в секунду и RPS, измеряемых при изменении #_users.
RPS следует уравнению для 1000 пользователей. Увеличение #_users после этого имеет убывающую отдачу с пределом, достигнутым примерно на 1200 пользователей. #_users здесь не независимая переменная, изменение времени ожидания также влияет на количество запросов в секунду. Однако изменение настройки эксперимента на 32 ядра (экземпляр c3.8x) или 56 ядер (в распределенной настройке) вообще не влияет на RPS.
Так действительно, как можно контролировать RPS? Есть ли что-то очевидное, что мне здесь не хватает?
