Реактивное программирование потребляет больше ресурсов, чем нереактивное? весна

В настоящее время мы сталкиваемся с проблемой производительности Spring WebFlux. Чтобы убедиться в преимуществах реактивного программирования, мы реализовали сервис Spring Boot, который извлекает данные из MongoDB и возвращает их через REST API потребителям.

Сервис существует в двух вариантах:

  1. Нереактивная реализация с Spring Boot, MongoRepository. Этот сервис возвращает данные в виде списка
  2. Реактивная реализация с Spring Boot, ReactiveMongoRepository, spring-boot-starter-webflux. Этот сервис возвращает данные как Flux.

В обеих реализациях контроллер REST напрямую выбирает данные из хранилища и возвращает их в виде списка соответственно. как поток. Дальнейшая логика приложения не выполняется.

Мы провели небольшой тест нагрузки / производительности с 100 пользователями, звонящими в службу, и обнаружили, что нереактивная реализация работала намного лучше, чем реактивная реализация.

Фактически, нереактивная реализация не только имела лучшую пропускную способность HTTP, но, что еще более интересно, она потребляла меньше ресурсов ЦП и меньше потоков, чем реактивная реализация! Это особенно противоречило ожиданиям, поскольку мы ожидали, что реактивная версия будет масштабироваться с небольшим количеством потоков, как указано в https://spring.io/blog/2016/07/28/reactive-programming-with-spring-5-0-m1

Нужно ли что-то подправить в настройках?

Кто-нибудь сталкивался с подобной проблемой?

Источник

1 ответ

Мы выполнили аналогичный тест с использованием Spring-Data-Reactive-Cassandra и Spring-Webflux против Spring-Data-Cassandra и Spring-MVC.

Мы протестировали оба сервера на 10000 запросов с параллелизмом 100 запросов / сек. Результаты не сильно удивили:-

Non Reactive Stack:-
         Concurrency Level:      100
         Time taken for tests:   22.945 seconds
         Complete requests:      10000
         Failed requests:        0
         Percentage of the requests served within a certain time (ms)
           50%    190
           66%    253
           75%    288
           80%    314
           90%    384
           95%    465
           98%    627
           99%    824
          100%   1208 (longest request)

Reactive Stack:-
         Concurrency Level:      100
         Time taken for tests:   30.061 seconds
         Complete requests:      10000
         Failed requests:        0
         Percentage of the requests served within a certain time (ms)
           50%    304
           66%    379
           75%    421
           80%    443
           90%    507
           95%    589
           98%    694
           99%    736
          100%    858 (longest request)

При выполнении этих тестов нереактивный стек порождал 147 потоков, а реактивный стек порождал 48 потоков.

Если вы сравните результаты, нереактивный стек немного быстрее по сравнению с реактивным стеком. Он сохранил 10 000 объектов в базе данных примерно за 23 секунды, в то время как реактивный стек занял примерно 30 секунд. Однако, если вы сравните 2% самых медленных запросов в двух стеках, реактивный стек окажется почти на 28% быстрее.

Реактивный стек с меньшим количеством потоков имел более равномерно распределенное время отклика. Ни один из запросов не был остановлен. В то время как для нереактивного стека 1% запросов был сравнительно ужасно медленным.

При увеличении количества вызовов в течение длительного периода времени реактивный стек сможет масштабироваться намного лучше по сравнению с нереактивным стеком. Поскольку количество потоков, которые вы можете создать на сервере, намного меньше, чем количество сокетов, которые вы можете открыть на сервере. Кроме того, во время этих тестов загрузка ЦП была менее 33% в обоих сценариях, что доказывает, что загрузка ЦП не ограничивает масштабируемость.

Нереактивный стек мог бы масштабироваться больше, если бы он не был ограничен переключением потоков и созданием потоков.

Источник

Позвольте мне попытаться объяснить возможные причины такого поведения. Реактивное приложение не работает быстрее, чем реактивное приложение. Реактивное приложение не позволяет системе простаивать, если очередь запросов не пуста. Поскольку вы тестировали при низкой нагрузке, вы не видели плюсов и минусов реактивного приложения, но видели снижение производительности. Производительность ниже, чем у неактивного приложения, потому что реактивное выполнение имеет небольшие накладные расходы.

Источник

http://blog.ippon.tech/spring-5-webflux-performance-tests/

Предлагаю вам прочитать эту статью. Есть результаты испытаний в реактивной пружине.

Источник
Другие вопросы по тегам