Długi czas odpowiedzi z serwera (po HTTP)

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:

1. Twoja aplikacja zemrzy bo wyczerpiesz swoją pule wątków.
   Tak bywa - *proste *rozwiązanie tego to olanie wątków i przejście na non blocking - spring webflux będzie ok.
2. 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:

1. 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
2. Może da się odwrócić komunikacje, żeby pozyskiwać dane a nie ciagle pytać