7

I'm setting up a web application, service oriented. The UI part (a web app) is consuming REST web services I'm coding too. So I have hand on both server and client side.

I was just wondering if it makes sense to set up HTTP keep-alive in such context. If it is, I'm curious as to why.

thanks in advance.

tckmn
  • 57,719
  • 27
  • 114
  • 156
Naoufel
  • 95
  • 1
  • 2
  • 8

1 Answers1

11

Yes, it does! From my testing on my server I can get 300 calls per seconds to my REST web service without keepalive, over 2000 with the keepalive on.

You will have to do some analysis on the usage patterns - often user-driven usage comes in bursts so it makes sense to keep the keepalive timeout quite short, just to handle a single burst.

thedayofcondor
  • 3,860
  • 1
  • 19
  • 28
  • 1
    Thanks for you response. is this the only advantage of keepalive in REST context? – Naoufel Nov 16 '12 at 12:06
  • 2
    Basically yes - negotiating a new TCP connection each time is time consuming - it can easily be few hundred ms, enough to give to the final user the idea "the site is slow" in some circumstances. As, if you use the keep-alive, the connection is transparently renegotiated when lost there is no harm in using it, it does not make your code more complicated, just adds a bit as speed. – thedayofcondor Nov 16 '12 at 12:48
  • 1
    @thedayofcondor having keep alive benefits if more requests are coming from same client, isn't it ? drawback of keeping connection alive is we may block new clients to create connection, correct me if I am wrong. – Bruce_Wayne Apr 25 '18 at 05:57
  • 1
    @Bruce_Wayne yes - if you want to keep exchanging data keep-alive avoids the costly TCP negotiation. Of course there is no such thing as a free beer and you pay in terms of extra resources used server side. However, there is no technical limit to the number of connections a server can keep open (but OSs have limits) and keep-alive is more of a polite negotiation between the server and the client - and the server can change its mind at any time if it is running out of resources, so in general I don't think it is an issue. – thedayofcondor Apr 27 '18 at 07:20
  • 1
    @thedayofcondor thanks for the reply, in some way it validated my understanding. I have another question out of curiosity now, as you said limits to the no. of connections is majorly due to OS limits(I agree), suppose a servers listens for 5 different endpoints for the rest service deployed on it and server can allow maximum of 1000 connection at any time, does this mean all endpoints will share these 1000 connections in any ratio depending upon the requests coming for which endpoint ? – Bruce_Wayne Apr 29 '18 at 17:28
  • 1
    Yes - the limit imposed by the OS is likely to preserve resources so it doesn't matter if there are 5 connections to the same endpoint or single connections to 5 different endpoints. For example, see https://stackoverflow.com/questions/410616/increasing-the-maximum-number-of-tcp-ip-connections-in-linux – thedayofcondor Apr 30 '18 at 18:00