Comments 12
С выходом Java 21 - Virtual Threads - использование реактивного стека теперь под большим вопросом. Смысл его теперь только в ограниченных случаях.
В целом, асинхронный подход (имхо) нужен только в двух случаях:
1) ваш язык не поддерживает многопоточность
2) вы слушаете более 10 тысяч сокетов одновременно
В остальных случаях асинхронность не дает преимуществ, а сложностей добавляет существенно. И в типовых веб-сервисах рабочие потоки в основном проводят время в ожидании ответа от базы данных или другого сервиса, поэтому вполне можно запускать до сотни потоков на ядро (ориентируясь на фактическую загрузку процессора).
Поправьте меня, пожалуйста, но тут вопрос не про синхронный/асинхронный подход в спринге и джаве, а REST vs SSE.
Вместо System.currentTimeMillis() лучше использовать System.nanoTime()
Я не очень понял причём здесь реактивность))
Эт какая-то односторонняя замена вебсокетам и лонгполингу похоже, что-то юзая словаMediaType.TEXT_EVENT_STREAM_VALUE и Flux.
Очень интересно, но придется догугливать наверно.
Как-то мало информации. В таком примере не видно преимуществ одного над другим. Когда есть смысл использовать одно, когда другое. Из примера пришли к выводу, что производительность первого и второго подхода равна...
Вот сколько "рекламных" статей про реактивку читал и везде юзают один и тот-же кейс с рестораном. Совершенно не отражающий суть процессов. В примере с рестораном оператор один. В реальности - получает оплату, отдает чек и переходит к следующему клиенту. Клиент ждет, когда придет заказ. В обычном нереактивном приложении "оператор" не один, более того, при увеличении нагрузки количество операторов увеличивается динамически. Физически и оператор и повар - один процесс. Никто никого не ждет, кроме случая доступа к диску, там ОС отправляет процесс поспать. Единственная проблема - суперпростой сервис, получающий десятки тысяч запросов в секунду, при котором создание процессов средствами ОС становится накладным. В обычных монолитных приложениях для бизнеса такого не бывает.
Сколько ни читал, никаких реальных преимуществ по времени реактивка не показывала, кроме специально сгенерированных случаев.
Создается впечатление, что реакт - очередная велосипедосамодеятельность. С внедрением легковесных потоков, решающих проблему суперпростых сервисов и тысячных нагрузок, реакт необходимо выбросить.
Так это обусловливается применением netty вместо томката. Имхо, использование томката в спринге и контейнере - какое-то извращение. Давно пора было сделать отдельную среду без встроенного веб-сервера.
Правильно сравнивать реакт с нормальным программированием можно, если и то и другое будет использовать один и тот-же томкат.
Пропробуйте exclude spring-boot-starter-reactor-netty from the spring-boot-starter-webflux dependency and use spring-boot-starter-tomcat . Тогда и можно будет сравнивать.
В netty нет и десятой доли (имхо, возможно вру) возможностей, какие предоставляет самостоятельный tomcat. Он не предусматривает быстрого запуска, это на постоянку запускаемый контейнер, который сдуру прикрутили в спринг.
Spring Boot. Реактивный асинхронный неблокирующий REST vs традиционный синхронный блокирующий