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

@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);
  }
}

• не вся логика доступна через endpoint;
  
• иногда хочется протестировать конкретный сервис или даже небольшой участок кода;
  
• для локальной проверки поднимать полноценный нагрузочный стенд часто слишком дорого и долго.

• сервис;
  
• repository;
  
• интеграция с БД;
  
• вызов внешнего API;
  
• или даже отдельный метод.

• локально;
  
• внутри integration tests;
  
• или как часть CI.

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 (если нужно симулировать ограниченные условия).

• что будет при высокой конкуренции за соединения?
  
• как система деградирует под нагрузкой?
  
• где начинаются блокировки и ожидания?
  
• как ведет себя код при параллельных транзакциях?

spring:
  jpa:
    hibernate:
      ddl-auto: create-drop
  datasource:
    hikari:
      # Для демонстрации исчерпания пула: мало слотов + короткое ожидание выдачи соединения
      maximum-pool-size: 20
      minimum-idle: 0
      connection-timeout: 500

================= 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
  
• запуск в контейнерах
  
• использование выделенных стендов

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    ...
}

• CPU usage
  
• heap memory
  
• количество активных задач
  
• прогресс выполнения

• latency (avg / p95 / p99)
  
• throughput
  
• пики CPU и памяти
  
• ошибки выполнения

• сравнить несколько прогонов;
  
• зафиксировать результаты для анализа;
  
• или просто сохранить историю изменений производительности.

@Test
  public void currentTest() {
    LoadTestReport report = RunnableChecker.run(
        RunnableTesting.builder()
            .requestCount(1000)
            .task(userService::createUser)
            .build()
    );
    CsvReportGenerator.generateRunnableReport("report/load-report.csv", report);
  }

• открыть в Excel / Google Sheets;
  
• сравнить разные конфигурации;
  
• построить свои графики поверх данных.

• что будет, если увеличить нагрузку в 10–100 раз?
  
• где упрется система: CPU, память или база?
  
• как быстро деградирует код при конкуренции?