I shared the results with Evan Phoenix (Puma's author) and here is what he had to say: "Wait til he sees Puma 2.0 with process clustering" ;)
You heard here first! - Matt On Mon, Aug 20, 2012 at 11:42 AM, Ylan Segal <[email protected]> wrote: > OK, here is my follow up. > > Indeed, I should have read httperf's manual more carefully, since I was > not testing what I thought I was testing. > > So, I now tried a different tool: siege. > > I ran a few concurrency scenarios for the 3 servers using something like: > > siege -c10 -t30s $URL > > (Run 10 cuncurrent requests on $URL, for 30 seconds). > > You can see a plot of the average response time for different servers and > concurrency settings: > > http://oi48.tinypic.com/65rjo7.jpg > > My interpretation: I can squeeze better performance from my dynos by > ditching thin for unicorn or puma. Unicorn seems to perform better than > puma when using concurrency > 20. (As mentioned before puma and thin were > using default configuration and unicorn is configured for 3 workers). All > test were running on heroku cedar with MRI ruby 1.9.3. > > Of course, this is mostly academic, since my website doesn't really have > that much traffic, but I was interested in seeing performance differences > by switching servers. > > What is the group's take on this? > > -- > Ylan Segal > [email protected] > Tel: +1-858-224-7421 > Fax: +1-858-876-1799 > > On Aug 18, 2012, at 7:34 AM, Ylan Segal wrote: > > > On Aug 17, 2012, at 6:17 PM, Matt Aimonetti <[email protected]> > wrote: > > > >> you might want to run that from within EC2 to avoid network latency, > then you might want to increase the concurrency (I believe you are > currently only sending 1 request at a time). > > > > I misunderstood the httperf manual. I thought I had a concurrency of 10. > That would explain why it didn't make much difference which server, used. > They were only processing 1 request a the time. > > > > I'll give it another try and post back. > > > >> Finally, if your code is waiting on IO for 45ms per request, this is > where your bottleneck is, not in the web server. > >> If that's the case, you want to try to increase the concurrency to see > when you hit the maximum amount of requests per processes available. > >> Thin is single threaded and blocking, so if your response if slow > because of a DB call for instance, 1.9 + Puma should give you a better > throughput. > >> Unicorn should also be able to fork more processes to handle the load > (depending on your settings and the available resources), Rainbows is also > an alternative web server based on unicorn and meant for slower response > times. > > > > Thanks. I'll look into rainbows as well. I also heard some news about > Goliath. > > > >> (it looks like, if you are really hitting your server, 50ms from your > home connection is quite a good response time tho) > > > > :) It is the homepage. I am caching the views, and made sure the caches > were warm before running the test. > > > > -- > > Ylan > > > > -- > > SD Ruby mailing list > > [email protected] > > http://groups.google.com/group/sdruby > > -- > SD Ruby mailing list > [email protected] > http://groups.google.com/group/sdruby > -- SD Ruby mailing list [email protected] http://groups.google.com/group/sdruby
