Описание
Я пытаюсь понять, почему пропускная способность sync rest api в ~ 6 раз хуже, чем async rest api.И как это исправить для этой масштабной модели.
Два реактивных микросервиса:
Manager, с конечной точкой отдыха webflux Worker, с @StreamListenerконечная точка сообщения, поддерживаемая Kafka
Синхронизация flow:
1. Manager receives a http request
2. Manager sends 'todo' message to Worker and waits*
3. Worker sends 'work-complete' message back to Manager
4. Manager responds to the http request
* Ожидание менеджера реализовано с помощью Mono.create / MonoSink .
Для Асинхронный поток , Manager немедленно отвечает на запрос и запускает отдельную цепочку Mono для связи с Worker.
.Производительность
Измерения - это время между входящим http-запросом Manager и work-complete сообщением, полученным от Worker.Пропускная способность - это количество сообщений, которое может обработать эта система, с 50 одновременными потоками jMeter.Все измеряется на бэкэнде с помощью dropwizard / метрик.
Flow | Min, ms | Max | 95% | Avg | Throughput
--------------|---------|-------|-------|-------|------------
sync | 28 | 1171 | 101 | 71 | 420 msg/s
async | 1096 | 18332 | 17876 | 12549 | 2454 msg/s
async +limit | 6 | 1163 | 114 | 72 | 420 msg/s
async +limit - тест, чтобы увидеть время обработки, с пропускной способностью, ограниченной значением пропускной способности синхронизации.
Вопросы
- Похоже, синхронизация API является узким местом.Что именно ограничивает пропускную способность?
- Есть ли лучший способ , чем этот для реализации sync api в webflux?
- Существуют ли какие-либо параметры webflux / netty / реактора, которые можно настроить для увеличения пропускной способности?
- Есть ли способ делегировать ожидание веб-серверу или шлюзу?Таким образом, «ожидающие» серверы можно масштабировать при низких затратах и бесплатных ресурсах на работающих серверах.
Код
https://github.com/archie-swif/sync-webflux-kafka