New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

best practices for closing connections? #56

Closed
jrochkind opened this Issue Apr 14, 2011 · 2 comments

Comments

Projects
None yet
3 participants
@jrochkind
Contributor

jrochkind commented Apr 14, 2011

So HTTPClient, unlike net::http, will leave a connection open until you specifically close it. I believe I've read some people saying that indeed leaving it open for multiple requests gets you much better performance.

But I'm not sure how to handle making sure it gets closed, or how important it is to make sure it gets closed.

In my project, it is convenient for me to have an internal API for making http requests, that uses HTTPClient under the hood. It is convenient for my own implementation to just lazily create an HTTPClient the first time a connection is needed, and then re-use that same HTTPClient instance on subsequent calls. But the problem there is that my architecture at present doesn't know for sure when it's done, or when to close it.

How big a problem would it be, for my local server, or for the remote servers I'm connecting to (some of which are really my servers too, but I don't want to be rude to third parties either) -- if I never close the connection? Eventually (unpredictable when) the HTTPClient will get GC'd by ruby -- I'm not sure if the sockets will be closed even then. How bad is it to both servers involved to never close the socket?

How do people handle this in their actual use cases? My app is actually a rails app, although a weird one. I guess I could have like an after_filter or something that calls my_http_client.reset_all . My actual app's weirdness involving some thread concurrency makes this harder, but I'm curious how people handle it in the 'standard' situation too.

Alternately, I could just NOT leave the connections open, I could just use one connection per request, like net::http, even though HttpClient is more powerful than that, I still could choose to use it that way, and then I wouldn't need to worry about closing it later. How bad an idea might that be, will performance actually suffer, or it will it not matter much?

Appreciate any advice, or stories of how people handle this in their actual situations.

nahi added a commit that referenced this issue Oct 13, 2011

Reuse cached session in MRU order, not in LRU
MRU is more server friendly than LRU because it reduces number of cached
sessions when a number of requests drops after an usaage spike.
Closes #68.

With reusing sessions in LRU order, all sessions are equally checked if
it's closed or not, as far as there's a request to the same site.  With
reusing sessions in MRU order, old cold sessions are kept in cache long
time even if there's a request to the same site.  To avoid this leakage,
this commit adds keep_alive_timeout property and let SessionManager
scrub all sessions with checking the timeout for each session.  When the
session expires against the last used time, it's closed and collected.

keep_alive_timeout is 15[sec] by default. The value is from the default
value for KeepAliveTimeout of Apache httpd 2.  This change is related
to #56.

@nahi nahi added the FeatureRequest label Nov 17, 2014

@nahi

This comment has been minimized.

Show comment
Hide comment
@nahi

nahi Dec 28, 2014

Owner

This ticket is 3.5 years old already... I think @jrochkind should not be interested in already... My bad, too late response.

I'm closing this with following comment.

In current HTTPClient implementation, Keep-Alive connections are closed by;

  • manually closed by HTTPClient#reset or HTTPClient#reset_all
  • when a connection is recycled but server closed the connection already.
  • when a connection is not used 15 seconds (keep_alive_timeout) after the last used (it's checked when HTTPClient is trying to issue a request if the request is at 15 or more seconds after the previous request)
  • GCed

So the best way to use I'm thinking is;

  1. Try to use the single HTTPClient instance wherever possible, even in multi-thread environment.
  2. If requests come constantly, change HTTPClient#keep_alive_timeout to be smaller, to 2 sec. or so, depending on usage.
Owner

nahi commented Dec 28, 2014

This ticket is 3.5 years old already... I think @jrochkind should not be interested in already... My bad, too late response.

I'm closing this with following comment.

In current HTTPClient implementation, Keep-Alive connections are closed by;

  • manually closed by HTTPClient#reset or HTTPClient#reset_all
  • when a connection is recycled but server closed the connection already.
  • when a connection is not used 15 seconds (keep_alive_timeout) after the last used (it's checked when HTTPClient is trying to issue a request if the request is at 15 or more seconds after the previous request)
  • GCed

So the best way to use I'm thinking is;

  1. Try to use the single HTTPClient instance wherever possible, even in multi-thread environment.
  2. If requests come constantly, change HTTPClient#keep_alive_timeout to be smaller, to 2 sec. or so, depending on usage.

@nahi nahi closed this Dec 28, 2014

@cntran

This comment has been minimized.

Show comment
Hide comment
@cntran

cntran Feb 11, 2016

After calling HTTPClient#reset_all how do you verify the connection has closed? This doesn't seem to be working in my app

cntran commented Feb 11, 2016

After calling HTTPClient#reset_all how do you verify the connection has closed? This doesn't seem to be working in my app

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment