No, passenger 5.0 is not faster than unicorn :)

No, passenger 5.0 is not faster than unicorn :)

[Bráulio Bhavamitra]

Hello all,

I've just tested a one instance each (one worker with unicorn and
--max-pool-size 1 passenger 5) on the rails app I work.

And the results are just as I expected, no miracle at all: Unicorn is
still the fatest!
(the difference is only a few milliseconds less per request)

The blocking design of unicorn is proving itself very efficient.

cheers!
bráulio

Re: No, passenger 5.0 is not faster than unicorn :)

[Sam Saffron]

I covered this here:
http://discuss.topazlabs.com/t/amidst-blizzards-they-rest/1147

it seems like an odd marketing move to me ... optimising a bit that
needs very little help. heck ripping out hashie and the 50 frames
omniauth injects would have a significantly bigger impact on rails
apps out there than optimising the 0.5% that needs little optimising.

On Wed, Dec 3, 2014 at 8:50 PM, Bráulio Bhavamitra <braulio@eita.org.br> wrote:
> Hello all,
>
> I've just tested a one instance each (one worker with unicorn and
> --max-pool-size 1 passenger 5) on the rails app I work.
>
> And the results are just as I expected, no miracle at all: Unicorn is
> still the fatest!
> (the difference is only a few milliseconds less per request)
>
> The blocking design of unicorn is proving itself very efficient.
>
> cheers!
> bráulio
>

Re: No, passenger 5.0 is not faster than unicorn :)

[Sam Saffron]

oops sent wrong link meant to send this

https://meta.discourse.org/t/raptor-web-server/21304/6

On Wed, Dec 3, 2014 at 8:56 PM, Sam Saffron <sam.saffron@gmail.com> wrote:
> I covered this here:
> http://discuss.topazlabs.com/t/amidst-blizzards-they-rest/1147
>
> it seems like an odd marketing move to me ... optimising a bit that
> needs very little help. heck ripping out hashie and the 50 frames
> omniauth injects would have a significantly bigger impact on rails
> apps out there than optimising the 0.5% that needs little optimising.
>
> On Wed, Dec 3, 2014 at 8:50 PM, Bráulio Bhavamitra <braulio@eita.org.br> wrote:
>> Hello all,
>>
>> I've just tested a one instance each (one worker with unicorn and
>> --max-pool-size 1 passenger 5) on the rails app I work.
>>
>> And the results are just as I expected, no miracle at all: Unicorn is
>> still the fatest!
>> (the difference is only a few milliseconds less per request)
>>
>> The blocking design of unicorn is proving itself very efficient.
>>
>> cheers!
>> bráulio
>>

Re: No, passenger 5.0 is not faster than unicorn :)

[Hongli Lai]

Unicorn *is* in general very good and very efficient, no doubt about that.
Eric Wong has made great design choices and is an excellent programmer.

Having said that, in certain specific cases there's still room for
improvement. That's why we focused so much on microoptimizations and
specific optimizations like turbocaching. Have you followed Phusion
Passenger's Server Optimization Guide?
https://www.phusionpassenger.com/documentation/ServerOptimizationGuide.html

Also, you have to ensure that your Rails app sets the correct caching
headers. By default, Rails sets "Cache-Control: private, no-store" so that
the turbocache cannot kick in. You should see very different results if you
add "headers['Cache-Control'] = 'public'" to your Rails app. If you need
any help with this, please feel free to contact me off-list. I'd be happy
to help. We have also a benchmarking kit so that you can double check the
results; email me if you're interested in this.

As Sam said, most of the time will be spent in the Rails app. But
turbocaching is one notable exception: it's the one feature that can speed
things up even if your app is slow - provided that you set HTTP caching
headers correctly.

Unicorn is excellent at what it does: it's a minimal server with a specific
I/O model that is supposed to be used behind a buffering reverse proxy.
There is nothing wrong with that, and for the workloads that it's designed
for, it's great. Phusion Passenger has merely chosen a non-generalist
approach that aims to squeeze additional performance from specific cases.
Of course, nothing's a silver bullet. Like any tool, it only works if you
use it correctly.

On Wed, Dec 3, 2014 at 10:50 AM, Bráulio Bhavamitra <braulio@eita.org.br>
wrote:

> Hello all,
>
> I've just tested a one instance each (one worker with unicorn and
> --max-pool-size 1 passenger 5) on the rails app I work.
>
> And the results are just as I expected, no miracle at all: Unicorn is
> still the fatest!
> (the difference is only a few milliseconds less per request)
>
> The blocking design of unicorn is proving itself very efficient.
>
> cheers!
> bráulio
>
>


-- 
Phusion | Web Application deployment, scaling, and monitoring solutions

Web: http://www.phusion.nl/
E-mail: info@phusion.nl
Chamber of commerce no: 08173483 (The Netherlands)

Re: No, passenger 5.0 is not faster than unicorn :)

[Sam Saffron]

Yeah, anonymous caching is super critical, we monkey it in here:
https://github.com/discourse/discourse/blob/master/lib/middleware/anonymous_cache.rb
to be honest this really should be part of rails.

On Wed, Dec 3, 2014 at 10:00 PM, Hongli Lai <hongli@phusion.nl> wrote:
> Unicorn *is* in general very good and very efficient, no doubt about that.
> Eric Wong has made great design choices and is an excellent programmer.
>
> Having said that, in certain specific cases there's still room for
> improvement. That's why we focused so much on microoptimizations and
> specific optimizations like turbocaching. Have you followed Phusion
> Passenger's Server Optimization Guide?
> https://www.phusionpassenger.com/documentation/ServerOptimizationGuide.html
>
> Also, you have to ensure that your Rails app sets the correct caching
> headers. By default, Rails sets "Cache-Control: private, no-store" so that
> the turbocache cannot kick in. You should see very different results if you
> add "headers['Cache-Control'] = 'public'" to your Rails app. If you need
> any help with this, please feel free to contact me off-list. I'd be happy
> to help. We have also a benchmarking kit so that you can double check the
> results; email me if you're interested in this.
>
> As Sam said, most of the time will be spent in the Rails app. But
> turbocaching is one notable exception: it's the one feature that can speed
> things up even if your app is slow - provided that you set HTTP caching
> headers correctly.
>
> Unicorn is excellent at what it does: it's a minimal server with a specific
> I/O model that is supposed to be used behind a buffering reverse proxy.
> There is nothing wrong with that, and for the workloads that it's designed
> for, it's great. Phusion Passenger has merely chosen a non-generalist
> approach that aims to squeeze additional performance from specific cases.
> Of course, nothing's a silver bullet. Like any tool, it only works if you
> use it correctly.
>
> On Wed, Dec 3, 2014 at 10:50 AM, Bráulio Bhavamitra <braulio@eita.org.br>
> wrote:
>
>> Hello all,
>>
>> I've just tested a one instance each (one worker with unicorn and
>> --max-pool-size 1 passenger 5) on the rails app I work.
>>
>> And the results are just as I expected, no miracle at all: Unicorn is
>> still the fatest!
>> (the difference is only a few milliseconds less per request)
>>
>> The blocking design of unicorn is proving itself very efficient.
>>
>> cheers!
>> bráulio
>>
>>
>
>
> --
> Phusion | Web Application deployment, scaling, and monitoring solutions
>
> Web: http://www.phusion.nl/
> E-mail: info@phusion.nl
> Chamber of commerce no: 08173483 (The Netherlands)
>
>

Re: No, passenger 5.0 is not faster than unicorn :)

[Xavier Noria]

I've often found Cache-Control: public to be of limited use in practice
because you cannot invalidate that cache by hand. (Sometimes that's fine of
course.)

While the reverse proxy cache could provide a mechanism for explicit
expiration, there may be caches between your servers and the client, a
corporate cache for example. Those other ones are out of your control.

I suggested an extension for Rack::Cache called r-maxage that got merged:

    https://github.com/rtomayko/rack-cache/pull/55

With that directive you trade the benefits of caching in intermediate
proxies with more expiration control locally.

Re: No, passenger 5.0 is not faster than unicorn :)

[Bráulio Bhavamitra]

Hello Hongli,

Thank you the guide, I've already learned a bit from it.

We already use nginx for static files and ssl and varnish for caching
public pages, so maybe turbocaching won't help too much.

In this test I've tested passenger in standalone mode (--max-pool-size
1) and unicorn with one worker. On a slow page, the variation was
minimal (~8.26 req/s in unicorn and ~8.11 in passenger). I haven't
tested fast and cacheable page.

Also, I've used ab for benchmarking. Next time will try wrk.

cheers,
bráulio

On Wed, Dec 3, 2014 at 8:00 AM, Hongli Lai <hongli@phusion.nl> wrote:
> Unicorn *is* in general very good and very efficient, no doubt about that.
> Eric Wong has made great design choices and is an excellent programmer.
>
> Having said that, in certain specific cases there's still room for
> improvement. That's why we focused so much on microoptimizations and
> specific optimizations like turbocaching. Have you followed Phusion
> Passenger's Server Optimization Guide?
> https://www.phusionpassenger.com/documentation/ServerOptimizationGuide.html
>
> Also, you have to ensure that your Rails app sets the correct caching
> headers. By default, Rails sets "Cache-Control: private, no-store" so that
> the turbocache cannot kick in. You should see very different results if you
> add "headers['Cache-Control'] = 'public'" to your Rails app. If you need any
> help with this, please feel free to contact me off-list. I'd be happy to
> help. We have also a benchmarking kit so that you can double check the
> results; email me if you're interested in this.
>
> As Sam said, most of the time will be spent in the Rails app. But
> turbocaching is one notable exception: it's the one feature that can speed
> things up even if your app is slow - provided that you set HTTP caching
> headers correctly.
>
> Unicorn is excellent at what it does: it's a minimal server with a specific
> I/O model that is supposed to be used behind a buffering reverse proxy.
> There is nothing wrong with that, and for the workloads that it's designed
> for, it's great. Phusion Passenger has merely chosen a non-generalist
> approach that aims to squeeze additional performance from specific cases. Of
> course, nothing's a silver bullet. Like any tool, it only works if you use
> it correctly.
>
> On Wed, Dec 3, 2014 at 10:50 AM, Bráulio Bhavamitra <braulio@eita.org.br>
> wrote:
>>
>> Hello all,
>>
>> I've just tested a one instance each (one worker with unicorn and
>> --max-pool-size 1 passenger 5) on the rails app I work.
>>
>> And the results are just as I expected, no miracle at all: Unicorn is
>> still the fatest!
>> (the difference is only a few milliseconds less per request)
>>
>> The blocking design of unicorn is proving itself very efficient.
>>
>> cheers!
>> bráulio
>>
>
>
>
> --
> Phusion | Web Application deployment, scaling, and monitoring solutions
>
> Web: http://www.phusion.nl/
> E-mail: info@phusion.nl
> Chamber of commerce no: 08173483 (The Netherlands)



-- 
"Lute pela sua ideologia. Seja um com sua ideologia. Viva pela sua
ideologia. Morra por sua ideologia" P.R. Sarkar

EITA - Educação, Informação e Tecnologias para Autogestão
http://cirandas.net/brauliobo
http://eita.org.br

"Paramapurusha é meu pai e Parama Prakriti é minha mãe. O universo é
meu lar e todos nós somos cidadãos deste cosmo. Este universo é a
imaginação da Mente Macrocósmica, e todas as entidades estão sendo
criadas, preservadas e destruídas nas fases de extroversão e
introversão do fluxo imaginativo cósmico. No âmbito pessoal, quando
uma pessoa imagina algo em sua mente, naquele momento, essa pessoa é a
única proprietária daquilo que ela imagina, e ninguém mais. Quando um
ser humano criado mentalmente caminha por um milharal também
imaginado, a pessoa imaginada não é a propriedade desse milharal, pois
ele pertence ao indivíduo que o está imaginando. Este universo foi
criado na imaginação de Brahma, a Entidade Suprema, por isso a
propriedade deste universo é de Brahma, e não dos microcosmos que
também foram criados pela imaginação de Brahma. Nenhuma propriedade
deste mundo, mutável ou imutável, pertence a um indivíduo em
particular; tudo é o patrimônio comum de todos."
Restante do texto em
http://cirandas.net/brauliobo/blog/a-problematica-de-hoje-em-dia