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] 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.
