Всем привет! Меня зовут Михаил, я работаю главным экспертом в ОТП Банке.
Я люблю тестировать свои решения и почти всегда пишу unit- и integration-тесты. Но вот с нагрузочным тестированием ситуация обычно совсем другая: о нем вспоминают ближе к релизу, когда архитектуру уже поздно менять.
В какой-то момент я поймал себя на мысли:
А как вообще заранее понять, сколько ресурсов будет потреблять сервис под нагрузкой?
Сколько памяти съест приложение? Когда упрется в CPU? Как поведет себя БД при разном кол-ве запросов?
Чтобы ответить на эти вопросы, я написал небольшую библиотеку для локального нагрузочного тестирования на Java Virtual Threads. Она запускает большое количество задач, собирает метрики и формирует отчет - прямо в консоли или в CSV.
Сегодня я покажу сам подход, разберу код библиотеки и оставлю ссылку на GitHub-репозиторий, чтобы вы могли попробовать ее у себя или адаптировать под свои задачи.
Что тестируем сегодня
Я написал небольшой и очень простой код. Создаем пользователя в бд и отправляем запрос на регистрацию в смежную систему:
@Service
@RequiredArgsConstructor
public class UserService {
private final UserRepository userRepository;
private final OtherSystemClient otherSystemClient;
@Transactional
public void createUser() {
String randomEmail = UUID.randomUUID() + "@gmail.com";
User user = buildUser(randomEmail);
otherSystemClient.registrationUser(new RegistrationDto(randomEmail));
userRepository.save(user);
}
private User buildUser(String randomEmail) {
return User.builder()
.email(randomEmail)
.status(UserStatus.NEW)
.isActive(true)
.name("Легенда")
.build();
}
}
@Component
public class OtherSystemClient {
public RegistrationResponseDto registrationUser(RegistrationDto dto) {
LockSupport.parkNanos(TimeUnit.MILLISECONDS.toNanos(10));
return new RegistrationResponseDto(UserStatus.SUCCESS.name(), null);
}
}Самый очевидный вариант - поднять приложение и начать дергать HTTP endpoint через Postman, JMeter или любой другой инструмент.
Но здесь появляются проблемы:
не вся логика доступна через endpoint;
иногда хочется протестировать конкретный сервис или даже небольшой участок кода;
для локальной проверки поднимать полноценный нагрузочный стенд часто слишком дорого и долго.
В итоге появляется странная ситуация:
мы умеем хорошо тестировать корректность кода, но почти не проверяем его поведение под реальной нагрузкой на ранних этапах разработки.
High-load-tester библиотека
Идея была простой:
хотелось получить нагрузочный тест буквально в несколько строк кода и запускать его на любом участке приложения - не только на HTTP endpoint.
Например:
сервис;
repository;
интеграция с БД;
вызов внешнего API;
или даже отдельный метод.
При этом тест можно запускать:
локально;
внутри integration tests;
или как часть CI.
Ниже - пример integration-теста.
Внутри TestContext поднимается PostgreSQL через Testcontainers, а сам тест запускается в обычном @SpringBootTest.
class UserServiceLoadCurveIT extends TestContext {
@Autowired
private UserService userService;
@Test
public void shouldCreateUsersWithMediumRpsCurrentWork() {
LoadTestReport report = RunnableChecker.run(
RunnableTesting.builder()
.requestCount(1000)
.task(userService::createUser)
.build()
);
Assertions.assertTrue(report.getErrors().isEmpty());
}
}И все, чтобы после этого мы получили полную сводку метрик, пример:
================= LOAD TEST REPORT =================
Total requests: 10000
Completed requests: 10000
Total duration: 1630 ms
Throughput: 6134.97 requests/sec
---------------- LATENCY ----------------
Average latency: 1165.37 ms
P95 latency: 1482.79 ms
P99 latency: 1491.56 ms
---------------- RESOURCES ----------------
Peak CPU usage: 51.45 %
Peak heap memory usage: 389 MB
Heap limit (MB): —
---------------- SNAPSHOTS ----------------
Collected metrics snapshots: 17
---------------- ERRORS ----------------
Errors count: 9763
====================================================Какие метрики собираются
Идея простая - не перегружать отчет сотнями метрик, а дать набор ключевых:
насколько быстро система обрабатывает нагрузку;
где находится latency (avg / p95 / p99);
упирается ли она в CPU или память;
есть ли ошибки и в каком объеме.
@Builder
@Getter
@AllArgsConstructor
@NoArgsConstructor
public class LoadTestReport {
/** Запрошенное число выполнений задачи (как в конфигурации). */
private long totalRequests;
/** Фактически завершённых задач после блока finally исполнителя. */
private long completedRequests;
/** Длительность всего прогона по настенным часам, миллисекунды. */
private long durationMs;
/** Завершённые запросы в секунду (число завершённых / длительность в секундах). */
private double throughput;
/** Средняя латентность одной задачи, миллисекунды. */
private double avgLatencyMs;
/** Оценка 95-го персентиля латентности, миллисекунды. */
private double p95LatencyMs;
/** Оценка 99-го персентиля латентности, миллисекунды. */
private double p99LatencyMs;
/** Максимальная оценка загрузки CPU по снимкам метрик, в процентах. */
private double peakCpuLoad;
/** Максимальный зарегистрированный объём heap по снимкам, мегабайты. */
private long peakMemoryMb;
/** Временной ряд снимков метрик во время прогона (может быть пустым). */
private List<MetricsSnapshot> snapshots;
/** Краткие сообщения об ошибках (ожидание future, лимит памяти и т.п.). */
private List<String> errors;
/** Лимит heap (МБ), скопированный из конфигурации; если не задавали — null. */
private Long heapLimitMb;
// логика сбора метрик
}Сам тест описывается через простой конфиг:
@Builder
@Getter
@NoArgsConstructor
@AllArgsConstructor
public class RunnableTesting {
/** Код одной единицы нагрузки; вызывается столько раз, сколько задано в поле ниже. */
private Runnable task;
/** Сколько раз отправить задачу в пул виртуальных потоков. */
private int requestCount;
/** Верхний предел используемого heap (МБ), или null — не проверять. */
private Long heapLimitMb;
}Сейчас библиотека поддерживает три базовых параметра:
сама нагрузочная задача;
количество запусков;
лимит heap (если нужно симулировать ограниченные условия).
Зачем это все нужно?
Давайте смоделируем довольно типичную ситуацию.
У нас есть приложение, которое работает с базой данных. И рано или поздно именно база становится узким местом - не CPU, не код, а количество одновременных подключений.
Хочется быстро ответить на вопросы:
что будет при высокой конкуренции за соединения?
как система деградирует под нагрузкой?
где начинаются блокировки и ожидания?
как ведет себя код при параллельных транзакциях?
Для примера ограничим пул подключений к БД:
spring:
jpa:
hibernate:
ddl-auto: create-drop
datasource:
hikari:
# Для демонстрации исчерпания пула: мало слотов + короткое ожидание выдачи соединения
maximum-pool-size: 20
minimum-idle: 0
connection-timeout: 500Теперь запускаем 1000 виртуальных потоков, каждый из которых пытается выполнить операцию с базой:
================= LOAD TEST REPORT =================
Total requests: 1000
Completed requests: 1000
Total duration: 587 ms
Throughput: 1703.58 requests/sec
---------------- LATENCY ----------------
Average latency: 440.37 ms
P95 latency: 566.43 ms
P99 latency: 567.26 ms
---------------- RESOURCES ----------------
Peak CPU usage: 27.73 %
Peak heap memory usage: 68 MB
Heap limit (MB): —
---------------- SNAPSHOTS ----------------
Collected metrics snapshots: 6
---------------- ERRORS ----------------
Errors count: 517
====================================================
Также я еще вывывел ошибки:
[org.springframework.transaction.CannotCreateTransactionException: Could not open JPA EntityManager for transaction и бла бла бла]С помощью такого подхода можно очень быстро менять условия эксперимента:
уменьшать или увеличивать pool;
менять количество конкурентных запросов;
проверять поведение кода при перегрузке БД;
находить узкие места до того, как это случится в проде.
Про ресурсы и честность локальных тестов
Когда начинаешь гонять нагрузочные тесты локально, быстро всплывает очевидная проблема:
твоя машина ≠ продакшен.
И это важно понимать.
Есть разные способы приблизить локальные тесты к реальности:
ограничение CPU (cgroups / Docker)
лимиты памяти (-Xmx, container limits)
имитация задержек сети
throttling через rate limit
запуск в контейнерах
использование выделенных стендов
Но важно другое: эта библиотека не пытается заменить полноценный load testing инструмент.
Ее задача другая:
быстро понять, как ведет себя конкретный кусок кода под конкурентной нагрузкой прямо в процессе разработки.
при необходимости тест можно дополнительно “приземлить” к реальным условиям - через Docker лимиты, настройку JVM или запуск в CI-окружении, но это уже слой над библиотекой, а не её ответственность.
Как все это работает
Теперь коротко разберем внутреннее устройство.
1. Запуск нагрузки через virtual threads
Все задачи отправляются в Executors.newVirtualThreadPerTaskExecutor():
try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
...
}Это позволяет дешево создать тысячи конкурентных задач без классических thread pool ограничений.
2. Сбор метрик во время выполнения
Параллельно запускается отдельный ScheduledExecutorService, который каждые 100 мс снимает:
CPU usage
heap memory
количество активных задач
прогресс выполнения
3. Постобработка результатов
После завершения прогона считаются:
latency (avg / p95 / p99)
throughput
пики CPU и памяти
ошибки выполнения
Возможность собирать отчеты в виде CSV
Иногда одного вывода в консоль недостаточно.
Например, когда нужно:
сравнить несколько прогонов;
зафиксировать результаты для анализа;
или просто сохранить историю изменений производительности.
Для этого в библиотеке есть возможность сохранить отчет в CSV:
@Test
public void currentTest() {
LoadTestReport report = RunnableChecker.run(
RunnableTesting.builder()
.requestCount(1000)
.task(userService::createUser)
.build()
);
CsvReportGenerator.generateRunnableReport("report/load-report.csv", report);
}CSV содержит все ключевые метрики прогона, поэтому его можно:
открыть в Excel / Google Sheets;
сравнить разные конфигурации;
построить свои графики поверх данных.
Итог
Эта библиотека - не попытка заменить полноценные инструменты нагрузочного тестирования.
Она про другое: быстрые локальные эксперименты, когда нужно понять, как ведет себя конкретный кусок кода под конкурентной нагрузкой, без подготовки стендов и сложной инфраструктуры.
По сути, это способ задать себе несколько простых вопросов прямо во время разработки:
что будет, если увеличить нагрузку в 10–100 раз?
где упрется система: CPU, память или база?
как быстро деградирует код при конкуренции?
Virtual threads здесь выступают просто как удобный механизм для генерации высокой конкуренции без накладных расходов на потоки.
Если у вас есть идеи, что еще можно добавить в такие локальные тесты — пишите, интересно сравнить подходы.
Мне было интересно исследовать, как virtual threads ведут себя под высокой нагрузкой и можно ли сделать JVM-native performance framework для тестирования Runnable/Callable без HTTP-слоя.
В процессе получился небольшой experimental framework, которого пока нет в maven.
Сама библиотечка - https://github.com/MishaBucha/high-load-tester/tree/develop
Всем спасибо за внимание!)