[P.....s]

Porównanie wydajności restowego serwisu w Spring Boot 2 WebFlux vs Spring Boot 1.

Korzystacie z programowania reaktywnego? Lubicie programowanie funkcyjne? Czy wolicie klasyczne podejście "encja na twarz i pchasz"?

#java #programowanie

[SwordPL]

@Philopolemus_Fronius: Osobiście jestem Javoscalowcem, więc funkcyjnie piszę ( ͡° ͜ʖ ͡°)

Masz jakiś fajny paper, artykuł czy coś na ten wykres? :) Czy to własne badanie? Chciałbym podzielić się z zespołem ( ͡° ͜ʖ ͡°)

[P.....s]

@SwordPL:

Takie dwa artykuły w sumie, chociaż swoje badania też nie byłoby jakoś ciężko zrobić :D

https://dzone.com/articles/spring-boot-20-webflux-reactive-performance-test
https://dzone.com/articles/raw-performance-numbers-spring-boot-2-webflux-vs-s

[cxnmlhuipwetr]

@Philopolemus_Fronius: jak zwykle - zależy. Jeśli bottleneckiem jest czas mielenia to jedyne co ci da programowanie reaktywne to możliwość szybkiego walnięcia 503 bez czekania na naturalny timeout z uwagi na brak workerów - ot zrobisz to samo co zrobi co pod spodem klasyczny serwer typu Tomcat tylko manualnie. Jeśli bottleneckiem jest I/O to jest to fajniejsze bo przy użyciu NIO jesteś w stanie kilkoma wątkami opędzić mnóstwo klientów (tak jak np

[P.....s]

@cxnmlhuipwetr: W artykule, który podlinkowałem masz wszystko napisane ;)

No ogólnie bottleneckiem jest zazwyczaj I/O, no chyba, że masz serwis, który wykonuje bardzo pracochłonne obliczenia, chociaż wtedy też raczej lepszym rozwiązaniem byłoby ogarnięcie requestów asynchronicznie a wymagająca zadanie puścić na workerze jakimś, który spokojnie to zrobi. Chociażby jak na youtubie, jak wgrasz film to nie musisz czekać z używaniem serwisu aż się przekonwertuje tylko tam sobie leci gdzieś

[Saly]

@Philopolemus_Fronius: wykres powinien mieć nazwę Tomcat vs Netty

[dan3k]

@Philopolemus_Fronius: niby fajnie, ale nie do wszystkich zastosowań webFlux jest tak dobrym rozwiązaniem, tak samo jak mikroserwisy i nosql. Serce mnie boli jak patrzę na wykresy, ale cytując Bieńkowską- sorry, taką mamy architekturę ( ͡° ʖ̯ ͡°)

[Koryntiusz]

@Philopolemus_Fronius: Przy większości web appek w springu i tak masz repozytoria oparte na JDBC które się blokuje więc trzeba to opakowywać w ThreadPool żeby zrobić z tego wersję "asynchroniczną". Jak ThreadPool się zapcha to kończy się wzrost wydajności.

[P.....s]

@Koryntiusz: Dlatego korzysta się z repozytoriów asynchronicznych, np Reactive MongoDB

[Koryntiusz]

@Philopolemus_Fronius: Jeśli możesz
- Nie przepiszesz wszystkich projektów na mongo jeśli już są bazach relacyjnych
- Nie wszystkim pasuje mongo

[P.....s]

@Koryntiusz: Wszystko da sie przepisać ( ͡° ͜ʖ ͡°)

[Koryntiusz]

@Philopolemus_Fronius: Jeśli klient Ci za to zapłaci i wszędzie na siłę wepchasz mongo to tak ;)

[P.....s]

@Koryntiusz: No najlepiej to uwzględnić w procesie projektowania aplikacji. JDBC ma swoją nieblokowalną wersję ale nie jest to jeszcze wprowadzone jako standard, nazywa się to ADBA

[Koryntiusz]

No najlepiej to uwzględnić w procesie projektowania aplikacji

@Philopolemus_Fronius: No tak, ale zwyczajnie możesz nie chcieć mongo w swojej architekturze.
Dzięki za info o ADBA, nie słyszałem o tym.

[patste]

@Philopolemus_Fronius: Na jakiej zasadzie działają asynchroniczne repozytoria? Jeśli masz jakąś transakcję, to po pierwszym zapytaniu do db inni klienci nie mogą korzystać z tego samego połączenia do db, bo wszystkie kolejne zapytania w tym połączeniu będą w tej samej transakcji aż do commita. Jeśli więc masz K połączeń w db pool i N klientów, to N – K klientów i tak musi czekać, żeby dostać wolne połączenie.

[P.....s]

@patste: meh, chodzi o to ze jak robisz zapis do bazy to nie czekasz tylko przetwarzasz reszte requestow. W klasycznym przypadku robisz zapis do bazy, czekasz ileś tam milisekund aż się zapisze i dopiero zaczynasz przetwarzać reszte requestow. Chodzi o blokowalne i nieblokowalne i/o a jak to jest zrobione to nie wiem, to jest zaimplementowane na poziomie bazy i systemu operacyjnego

[patste]

@Philopolemus_Fronius: podejrzewam, że jeśli nie każdy request musi się łączyć z db, to ma to sens, bo te requesty nie będą musiały czekać. W sumie thread/req daje to samo bez konieczności używania nonblocking io

[P.....s]

@patste: Tylko thread/req się nie skaluje co pokazuje właśnie wykres przeze mnie wstawiony

[patste]

@Philopolemus_Fronius: Twój wykres mierzy dużo więcej rzeczy niż tylko async io vs thread/req. async io nie zawsze jest szybsze, bo zazwyczaj wymaga więcej pracy, i.e. musisz dodać socket do epoll/kqueue, dodatkowy kod w reactorze musi zostać wykonany etc.
Kilka miesięcy temu bawiłem się w async io i zrobiłem kilka benchmarków. echo server przy 20k równoczesnych połączeniach: 419k req/s używając boost.asio i 389k req/s używając thread/conn ;)
Zobacz też to:
https://medium.com/netflix-techblog/zuul-2-the-netflix-journey-to-asynchronous-non-blocking-systems-45947377fb5c