-
Notifications
You must be signed in to change notification settings - Fork 34
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
Heroics should use keep-alive connections #16
Comments
Probably pretty straightforward to do by creating a connection on the client (and then reusing it). |
Yep, it shouldn't be too hard. Right now connections are created in |
I think I understand what you're suggesting here, but I want to verify it. Are you talking about making a single connection, basically opening up a socket and then re-using that socket for future requests? Is that correct? I took a look at connection = Excon.new(@root_url, thread_safe_sockets: true) Then later we're making the request: connection.request(options) Do you have any examples of using keep-alive connections with excon to follow that someone could use? Is there a way we can write an example script with keep-alive connections to quantify the speedup potential? If we had benchmarks, that show this to be a significant speedup then we could possibly prioritize this work. |
If I understand correctly, the assertion is that |
The Excon readme mentions a connection = Excon.new('http://geemus.com', :persistent => true) Could it be that we should simply use this option? Then there would be no need to pass the connection around. |
Hey, sorry for the long radio silence, I guess I lost track of this at some point. To make things work as persistent, we would want to BOTH create a connection and the client level and reuse it across links (instead of creating a new connection in each link) AND set the persistent option on this new connection. All that being said, as I recall the reason that persistent is false by default with excon is because the behavior from the server is really inconsistent and problematic. In particular, though most servers technically support keep-alive they also have a relatively short timeout on connections. Furthermore in many cases it seemed that the timeout starts when the connection is opened and did not refresh on activity. So as an example, you might have better performance for whatever requests you manage to do within the first 30 seconds of the socket, and then it would just fail. And the failure in this case can also be a race condition, ie perhaps your request got through and it timed out before responding, in that case you don't get a response because the socket is closed, but maybe the action still occurred? I hope that makes sense, let me know if you have questions and I can try to explain further. Taken all together, it can be a good idea to setup connections and allow an option for users to toggle persistent on if they think it is worth it and know what they are doing. ie some servers actually allow for longer keep-alive and so don't have problematic behavior, or if you know all your requests are idempotent you can allow it to fail and simply refresh the connection and retry. BUT it's probably not a reasonable default for general usage, as my experience of actually trying to use it in practice have been quite really mixed at best. |
This would probably give us some nice speedups.
The text was updated successfully, but these errors were encountered: