Comments on: An analysis of Ruby 1.8.x HTTP client performance http://apocryph.org/2008/10/04/analysis_ruby_18x_http_client_performance/ Notes to my future self Sat, 13 Mar 2010 18:32:23 -0600 http://wordpress.org/?v=2.8.6 hourly 1 By: anelson http://apocryph.org/2008/10/04/analysis_ruby_18x_http_client_performance/comment-page-1/#comment-379 anelson Thu, 26 Feb 2009 00:32:42 +0000 http://apocryph.org/?p=584#comment-379 I actually did in my follow-up article. I had trouble getting it to run. I actually did in my follow-up article. I had trouble getting it to run.

]]> By: Kostroma http://apocryph.org/2008/10/04/analysis_ruby_18x_http_client_performance/comment-page-1/#comment-378 Kostroma Wed, 25 Feb 2009 22:43:57 +0000 http://apocryph.org/?p=584#comment-378 You should have a look a RightScales http_connection gem too. Seems that there are bunch of other stuff that Net::HTTP is missing too . e.g support for HTTP Status: 100 Continue You should have a look a RightScales http_connection gem too. Seems that there are bunch of other stuff that Net::HTTP is missing too . e.g support for HTTP Status: 100 Continue

]]> By: anelson http://apocryph.org/2008/10/04/analysis_ruby_18x_http_client_performance/comment-page-1/#comment-362 anelson Tue, 10 Feb 2009 20:42:52 +0000 http://apocryph.org/?p=584#comment-362 In my case the test data are compressed zip files, so further compression is unlikely. In my case the test data are compressed zip files, so further compression is unlikely.

]]> By: hgs http://apocryph.org/2008/10/04/analysis_ruby_18x_http_client_performance/comment-page-1/#comment-358 hgs Fri, 06 Feb 2009 14:22:17 +0000 http://apocryph.org/?p=584#comment-358 But if the compression reduces it to 8MB? But if the compression reduces it to 8MB?

]]> By: anelson http://apocryph.org/2008/10/04/analysis_ruby_18x_http_client_performance/comment-page-1/#comment-355 anelson Thu, 05 Feb 2009 23:04:55 +0000 http://apocryph.org/?p=584#comment-355 That's true, but I don't see how that would materially effect the results, since the test consists of a download of a 10MB data file. Even if curb caches connections between instances (which seems unlikely but let's say it's true) the overhead associated with establishing the HTTP connection would surely be amortized by the overhead associated with 10MB of data transfer. That’s true, but I don’t see how that would materially effect the results, since the test consists of a download of a 10MB data file. Even if curb caches connections between instances (which seems unlikely but let’s say it’s true) the overhead associated with establishing the HTTP connection would surely be amortized by the overhead associated with 10MB of data transfer.

]]> By: Aaron Patterson http://apocryph.org/2008/10/04/analysis_ruby_18x_http_client_performance/comment-page-1/#comment-354 Aaron Patterson Thu, 05 Feb 2009 22:26:47 +0000 http://apocryph.org/?p=584#comment-354 These tests do not take in to account keep alive requests. Curb does keep alive requests and keeps connections open by default, where net/http does not. These tests do not take in to account keep alive requests. Curb does keep alive requests and keeps connections open by default, where net/http does not.

]]> By: hgs http://apocryph.org/2008/10/04/analysis_ruby_18x_http_client_performance/comment-page-1/#comment-335 hgs Fri, 30 Jan 2009 10:55:28 +0000 http://apocryph.org/?p=584#comment-335 You have not stated which of these servers support compression, and whether this was used at the time. I created patches to allow compression to be used in Net::HTTP and these were accepted. Every post I see about the slowness of this library seems to ignore this aspect. Probably in the local case (Dallas) this will make no difference, just adding to the unpacking time, but given that compression has been part of the protocol for a long time, this seems to be a fair question to ask. You have not stated which of these servers support compression, and whether this was used at the time. I created patches to allow compression to be used in Net::HTTP and these were accepted. Every post I see about the slowness of this library seems to ignore this aspect. Probably in the local case (Dallas) this will make no difference, just adding to the unpacking time, but given that compression has been part of the protocol for a long time, this seems to be a fair question to ask.

]]> By: roger http://apocryph.org/2008/10/04/analysis_ruby_18x_http_client_performance/comment-page-1/#comment-196 roger Fri, 24 Oct 2008 18:16:26 +0000 http://apocryph.org/?p=584#comment-196 Feel free to post patches. Esp. for 1.8.7 and 1.9 they're welcome. -=R Feel free to post patches. Esp. for 1.8.7 and 1.9 they’re welcome.
-=R

]]> By: anelson http://apocryph.org/2008/10/04/analysis_ruby_18x_http_client_performance/comment-page-1/#comment-197 anelson Thu, 16 Oct 2008 13:51:54 +0000 http://apocryph.org/?p=584#comment-197 Good idea. I have some further testing I want to perform with some more implementations, but when I'm done I'll try to put something together. Good idea. I have some further testing I want to perform with some more implementations, but when I’m done I’ll try to put something together.

]]> By: hgs http://apocryph.org/2008/10/04/analysis_ruby_18x_http_client_performance/comment-page-1/#comment-198 hgs Wed, 15 Oct 2008 23:29:54 +0000 http://apocryph.org/?p=584#comment-198 I've just had a poke around inside the Ruby Issue Tracker http://redmine.ruby-lang.org/ and this problem seems to be unmentioned in things that are still open. It might be an idea to put something constructive there about possible lines of attack for this problem. I’ve just had a poke around inside the Ruby Issue Tracker

http://redmine.ruby-lang.org/

and this problem seems to be unmentioned in things that are still open. It might be an idea to put something constructive there about possible lines of attack for this problem.

]]>