Блог

Описание

Я пытаюсь понять, почему пропускная способность sync rest api в ~ 6 раз хуже, чем у async rest api. И как это исправить для этой масштабной модели.

Два реактивных микросервиса:

• Manager с конечной точкой webflux rest
• Worker с конечной точкой сообщения @StreamListener, поддерживаемой Kafka

Поток синхронизации:

 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 / metrics.

       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 — проверьте время обработки, при этом пропускная способность ограничена значением пропускной способности синхронизации.

Вопросы

1. Похоже, что sync api является узким местом. Что именно ограничивает пропускную способность?
2. Есть ли лучший способ, чем этот, реализовать sync api в webflux?
3. Существуют ли какие-либо параметры webflux / netty / reactor, которые можно настроить для увеличения пропускной способности?
4. Есть ли способ делегировать ожидание веб-серверу или шлюзу? Чтобы «ожидающие» серверы можно было масштабировать с низкой стоимостью и свободными ресурсами на рабочих серверах.

Код

https://github.com/archie-swif/sync-webflux-kafka