Performance tuning Spring Rest Template

Background : I am using spring boot with embedded jetty. My app calls bunch of rest apis. For calling these rest apis I use spring rest template. Question: Is Spring rest template any good at high concurrency? Searching on the web search suggests moving to reactive but still there are apps which are written in blocking way and need to continue that way. Question is what alternate is there or what can be done to make rest template more responsive under heavy load. PoolingHttpClientConnectionManager improves things a bit but essentially still not at par with is required.

There are suggestions to move to rest easy and other http clients but no slid reasoning behind it. End of the day, they all make pool of connections and essentially works the same. Please note, reactive is not an option yet. This question is very specific to traditional blocking rest calls. Any suggestions in optimizing connection pooling or using rest template right will be of great help.

This Post Has One Comment

  1. No Fault

    RestTemplate does not do an actual rest call by itself, its just a “wrapper” – a convenient API.

    Now when it comes to connection pooling, by default it doesn’t use any kind of pooling and just opens URL connections available in Java anyway. No third-parties are required, but performance is not so good.

    You can configure rest template to use, say, OkHttp Client under the hood. See here for different ways to work with different clients. The interesting part is that its possible to configure connection pools there and achieve a better performance.

    So you should really check what exactly the expected performance is and configure the connection pool accordingly.

    Now one more thing about Reactive stuff – it won’t give you a performance gain, however it will allow to serve better multiple concurrent requests by reusing resources more efficiently. However if you’ll measure how long it takes to perform one single request – its not expected to be performed faster.

    In other words you should consider the transition to reactive stack if the application has too many concurrent requests that it can’t serve, but not if you want to process every single request faster.

Leave a Reply