Я просто тестирую на примере проекта PoC некоторые блокирующие / неблокирующие решения в простом распространенном сценарии.
Сценарий:
- Есть конечная точка блокировки отдыха, которая довольно медленная - каждый запрос занимает 200 мс.
- Есть и другое - клиентское приложение, которое вызывает эту медленную конечную точку.
Я протестировал текущий (блокирующий) загрузочный клиент Spring (tomcat), Spring Boot 2.0 (netty) с помощью WebFlux - WebClient, Ratpack и Lagom. В каждом случае я подчеркнул клиентское приложение с помощью простого сценария тестирования Gatling (100-1000 пользователей в секунду).
Я протестировал ratpack и lagom в качестве эталонных неблокирующих серверов io, чтобы сравнить результаты с весенней загрузкой (с блокировкой и без блокировки).
Во всех случаях я получил ожидаемые результаты, за исключением теста Spring Boot 2.0. Он работает только при небольших уровнях нагрузки, но даже тогда с большой задержкой. Если уровень нагрузки повышается - все запросы отключаются по времени.
Использование WebClient:
@RestController
public class NonBlockingClientController {
private WebClient client = WebClient.create("http://localhost:9000");
@GetMapping("/client")
public Mono<String> getData() {
return client.get()
.uri("/routing")
.accept(TEXT_PLAIN)
.exchange()
.then(response -> response.bodyToMono(String.class));
}
}
Я понятия не имею, что идет не так, или текущая версия снимка просто работает.
Все источники опубликованы на https://github.com/rutkowskij/blocking-non-blocking-poc
- blocking-service - медленная блокирующая конечная точка
- неблокирующий клиент - клиент на основе Spring Boot 2.0 и WebClient
Я только что создал простое приложение Spring Boot, используя spring-boot-starter-webflux с версией 2.0.0.BUILD-SNAPSHOT, которое приносит spring-webflux версии 5.0.0.BUILD-SNAPSHOT и то же самое для Spring Core, Beans, Context и т. Д.
