The test was done on a single dyno. For unicorn, I used 3 workers (If I used more, then I exceeded the RAM limit). For puma, I used the default (which I think it's up to 16 threads).
I wrote a bit more about this on: http://ylan.segal-family.com/blog/2012/08/20/better-performance-on-heroku-thins-vs-unicorn-vs-puma/ It has been brought to my attention that for puma to really shine, you need to use jruby or rubinius (specifically not MRI with the GIL). I believe jruby is now available on heroku, but have not had a chance to try it. -- Ylan Segal [email protected] On Friday, May 3, 2013 at 11:33 AM, Clark Li wrote: > Ylan, how many dynos were involved? Did you check how many thread/procs were > actually created by the server for unicorn and puma? > > I'm evaluating between unicorn and puma as well. It seems that puma has the > potential to spawn more workers per dyno, since threads are lower overhead > than procs. > > - Clark > > On Monday, August 20, 2012 11:42:23 AM UTC-7, Ylan 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] (javascript:) > > 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] > > > (javascript:)> 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] (javascript:) > > > http://groups.google.com/group/sdruby > > > > -- > -- > SD Ruby mailing list > [email protected] (mailto:[email protected]) > http://groups.google.com/group/sdruby > --- > You received this message because you are subscribed to the Google Groups "SD > Ruby" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] > (mailto:[email protected]). > For more options, visit https://groups.google.com/groups/opt_out. > > -- -- SD Ruby mailing list [email protected] http://groups.google.com/group/sdruby --- You received this message because you are subscribed to the Google Groups "SD Ruby" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
