Локальное нагрузочное тестирование в Java с использованием Virtual Threads

[Artemik]

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

Например, 5000 RPS, 100 ms p95 совсем не означает, что сервис способен стабильно выдерживать такой RPS при такой p95 latency. В burst тестах это работает по другому.

RPS - это у вас (и обычно везде) значение от N и total duration, то есть просто среднее за всё время. В отличие от других тестов, для burst это критично, так как скрывается информация во времени. Например, если 100 запросов обработалось скопом в конце последней 5й секунды, получим 20 RPS. Но это очевидно не означает, что сервис стабильно способен на 20 RPS.

Latency p95 - у вас это “95% запросов из пачки завершились не позже этого значения”. Хотя это технически верно, это совсем не “сервис будет столько стабильно выдавать”.

С latency в вашем сетапе еще можно ошибиться вот с этим - если сервис уже был насыщен, то увеличивая N запросов кажется что увеличиваешь длительность теста, а на самом деле увеличится нагрузка и p95. Наивное “Total requests: 1000” подталкивает к такой ошибке.

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

В вашем сетапе нельзя протестировать baseline latency, то есть без параллельности. У вас задается пачка, и всё тут.

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

Лучше не выдумывать, и делать нормальные полноценные constant concurrency / constant arrival RPS тесты правильными внешними инструментами. Смотреть на send vs actual RPS. Делать длительные тесты, при которых клиенты успевают поработать, а потому получаемый RPS будет отражать реальную картину. Играться и смотреть в какой момент сервис перестает справляться, чтобы понять точку насыщения. Итд. Смысла пытаться отвязаться от http большого нет, это всё равно придется тестировать.

Если всё же хочется написать самому, тестировать изнутри jvm, уметь считать перфоманс при типичной нагрузке (к чему вы и клоните в статье), а не узковыраженный burst сценарий, и чтобы не сильно сложно - так и реализуйте тот же constant concurrency. Стоит тех же усилий. N workers (virtual threads) вызывают операцию в цикле в течение T duration. Всё. Получите те же метрики, но намного более честные и понятные.