Hej,
Mam taki usecase że stukam z aplikacji po HTTP po dane, które się długo mielą. Czekam po 4-5, czasem 6 sekund na response.
Możecie doradzić jak to usprawnić by nie zajechać aplikacji? Boję się że w obecnym przypadku - gdy kilkudziesięciu klientów odpali tą funkcjonalność to wszystkie wątki w mojej spring bootowej aplikacji będą zajęte oczekiwaniem na response.
przyśpieszyć "mielenie" danych. Nie bardzo wiem gdzie "stukasz" - do własnego serwisu czy do cudzego? Jak do cudzego to co byś chciał zmienić, żeby było szybciej?
@platinium: Zrób te zapytanie HTTP asynchronicznie.
A za co dokładnie odpowiada ten cudzy serwis? Może nieoptymalnie korzystasz z jego API?
@abrakadaber Zakładam że robi zapytanie do serwisu -> mapuje odpowiedź na inną -> zwraca odpowiedz.
Jeśli tak to niech OP popatrzy na to - https://blog.davidvassallo.me/2019/11/04/speeding-up-spring-mvc-with-completablefuture/ . Jak nie chcesz zajechać aplikacji a nie zależy ci na performancie, to zdefiniuj własny thread pool z ograniczoną ilością wątków i używaj tylko jego do wywoływania tych restów.
@CountZero: mi się wydaje, że to co pisze pytacz to jakiś middleware (ma jeszcze jakichś klientów). W tym kontekście Twoja ostatni odpowiedz może być rozwiązaniem, które nie spowoduje skończenia się zasobów - coś jak telefoniczne "jesteś 1634 w kolejce, proszę czekać". Jednak nie zmienia to faktu, że czas odpowiedzi będzie tylko rósł... @platinium może jakiś cache dla danych już otrzymanych?
Czekam po 4-5, czasem 6 sekund na response.
Możecie doradzić jak to usprawnić by nie zajechać aplikacji? Boję się że w obecnym przypadku - gdy kilkudziesięciu klientów odpali tą funkcjonalność to wszystkie wątki w mojej spring bootowej aplikacji będą zajęte oczekiwaniem na response.
Nie powinno być tak że jeśli tak długo czekasz to korzystasz w tej samej puli wątków w całej aplikacji. Jest to system zewnętrzny? Możesz cachować dane i czy cachowanie ma sens w tym przypadku?
Są dwa problemy:
- Twoja aplikacja
zemrzy
bo wyczerpiesz swoją pule wątków.
Tak bywa - *proste *rozwiązanie tego to olanie wątków i przejście nanon blocking
- spring webflux będzie ok. - Zemrze serwis, z którego korzystasz bo go zarypiesz żądaniami. Po przejściu na non blocking to się często zdarza - zrobiłem to nie raz
Rozwiązanie to rate limiter i circuit breaker - jest kilka rozwiązań na to. Z gotowców to można użyć https://resilience4j.readme.i (integruje się z reactorem, a przez to webflux)
Do podejścia non-blocking dodam jeszcze:
- Może wystarczy osobna monitorowana pula wątków, żeby moc to skalowac i nie wyczerpać własnej puli. Tutaj zalecałbym ostrożność i zrobienie testów wydajnościowych, czy rzeczywiście ten drugi serwis wytrzyma większy load
- Może da się odwrócić komunikacje, żeby pozyskiwać dane a nie ciagle pytać