Here are some preliminary benchmarks, done with a fresh Rails 2.3.8 app, ruby 1.8.7, and a single render :nothing => true.
It does seem multipart forms are a bit slower overall, although they were faster under webrick for a high number of parameters. As far as I could tell the numbers scaled linearly. In concrete terms, for Passenger, when posting 1000 simple parameters the speed penalty is 0.764 ms (yes milliseconds). Will repeat with a Rails 3 app too and post those results. Benchmark script: http://gist.github.com/442546 Webrick: = 1 key/value pair, 1000 posts user system total real default: 1.320000 0.150000 1.470000 ( 15.797317) multipart: 1.400000 0.130000 1.530000 ( 16.273821) = 1000 key/value pairs, 1000 posts user system total real default: 26.170000 0.570000 26.740000 ( 74.681545) multipart: 26.130000 0.540000 26.670000 ( 74.073439) Passenger = 1 key/value pair, 1000 posts user system total real default: 1.250000 0.160000 1.410000 ( 25.887364) multipart: 1.300000 0.150000 1.450000 ( 26.857967) = 1000 key/value pairs, 1000 posts user system total real default: 26.060000 0.510000 26.570000 ( 70.453057) multipart: 26.060000 0.480000 26.540000 ( 71.216598) On 17 jun, 16:47, Joost Baaij <[email protected]> wrote: > I can take a stab at this using AB, not until after next week due to a short > vacation though. > > Op 17 jun 2010, om 16:43 heeft Prem Sichanugrist het volgende geschreven: > > > > > > > +1 on benchmarking result. would love to see from > > > - Apache + Passenger > > - Nginx + Passenger > > - Mongrel > > - Thin > > - Webrick > > > What should be the method of benchmark? > > > On 17 มิ.ย. 2553, at 21:40, Hongli Lai wrote: > > >> On Jun 17, 9:29 am, Joost Baaij <[email protected]> wrote: > >>> Yes there are: multipart forms send more data since every field has its > >>> own MIME header. From RFC2388: > > >>> "The multipart/form-data encoding has a high overhead and performance > >>> impact if there are many fields with short values. However, in practice, > >>> for the forms in use, for example, in HTML, the average overhead is not > >>> significant." > > >>> If this overhead was deemed not significant in August 1998, in my opinion > >>> it is even less significant now and this is a change we could make > >>> without any problems. > > >> I don't think multipart parsing is very expensive nowadays, but I have > >> some doubts about the efficiency of the Rails/Rack multipart parser. > >> It performs a lot of string operations and if it creates a tempfile > >> even for small files then it can totally kill parsing performance. > > >> Someone should benchmark this stuff. > > >> -- > >> You received this message because you are subscribed to the Google Groups > >> "Ruby on Rails: Core" group. > >> To post to this group, send email to [email protected]. > >> To unsubscribe from this group, send email to > >> [email protected]. > >> For more options, visit this group > >> athttp://groups.google.com/group/rubyonrails-core?hl=en. > > > -- > > You received this message because you are subscribed to the Google Groups > > "Ruby on Rails: Core" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]. > > For more options, visit this group > > athttp://groups.google.com/group/rubyonrails-core?hl=en. > > Vanaf 18 juni ben ik een week op vakantie. > From June 18 I will be on vacation for a week. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
