Good work by Phusion guys (as usual). It is extremely heartening to see renewed focus on performance by them.
I was a little disappointed to read this comment though:
Needless to say, we’ve performed our own benchmarks already and have concluded
that “the self-proclaimed fastest deployment solution” really isn’t
the fastest deployment solution compared to Phusion Passenger 3. ;-)
The comment seemed a little snarky to me. Never met these folks in person, but all I have heard is good things about them. So, I hope it was just a tongue in cheek comment about the competitor solution. :-)
Most of the times competition is good for everyone, as it raises the bar and in general improves helps improve the quality of the solutions.
Hope they keep coming up with more such good things in future.
No problem. However several users have contacted us in the past about not only your blog post, but also the skewed benchmark graph on your front page. The skewing makes it appear as if your number is much (2x) higher which people apparently perceive as misleading. We've never made a fuss about this but now that you're mentioning it I might as well tell you.
I understand your point about the front page graph on the WebROaR site. The only thing I can say on a public forum is that the project is being done inside an organization, and you might know, developers ain't always in control of everything (except perhaps their code). :-). Why would I move out of a project that I had so much fun creating ..
I'll just leave it here for now.
If you ever happen to visit India, do let me know, would be happy to catch up over a beer (or your favorite drink).
That said, benchmarks are lies, lies, lies, damn lies of course
A hyperbolic warning, to not believe the hype.
I like the move to zero-copy, though. I think that's the right thing to do. I wrote a Smalltalk zero-copy templating engine for an in-house web application server in the early 2000's. I think zero-copy is one case where it's not pre-optimization to plan ahead. We didn't get this far, but we could've implemented some buffer caches and put the vast majority of the templating stuff into Perm-Space where the garbage collector wouldn't have to touch it at all!
I'm always happy to get free performance improvements, so it looks like a job well done. However, they note that "It’s not very useful to benchmark Phusion Passenger performance using a Rails application because most of the time is spent in Rails and the application itself." - which I would take to mean that in real world usage, this improvement really isn't going to buy me much. Still, nice work, and thank you!
this improvement really isn't going to buy me much
I think what they were saying is that they wanted to benchtest raw Passenger performance instead of Rails performance. Your Rails app will almost certainly see some benefit from Passenger 3, but they didn't want to distort their testing by throwing Rails into the mix. Makes sense to me.
That they wanted to benchmark their own stuff rather than Rails is blatantly obvious.
My point is that if, in my Rails app, 5% of the time is taken up by Passenger in a typical request, even big improvements like these are just not going to mean much in the real world.
Perhaps they can shed some light on what real world percentages of request time for Passenger vs Rails+App might look like.
Well the thing is there is no such thing as a single "real world percentage". If you want to know what the percentage is for you, you should benchmark it yourself.
A Hello World page would give a good lower bound for Rails' part of things, I think... Beyond that, it's only going to take up more of the total, right?
This is slightly off-topic, but It's nice to see that Phusion updated their branding and website. It's been a while since I've visited that site, but that stupid graffiti tag logo they had before was awful. The new look helps me take them more seriously.
We're in the progress of migrating our sites to the new design. Not everything has been migrated yet because we need to set priorities... like making Phusion Passenger faster. :)
>Optimizing algorithms and optimizing Ruby code in C
> Some key Ruby code has been replaced by C code.
Ew. I feel sorry for them. "C for speed" is C for a calcifying creep across your application. Necessary at times, but only if your language isn't good enough.
I was a little disappointed to read this comment though:
The comment seemed a little snarky to me. Never met these folks in person, but all I have heard is good things about them. So, I hope it was just a tongue in cheek comment about the competitor solution. :-)Most of the times competition is good for everyone, as it raises the bar and in general improves helps improve the quality of the solutions.
Hope they keep coming up with more such good things in future.
Disclaimer: I am the co-creator of the 'self proclaimed fastest ..' referred in the post. - http://webroar.in/blog/2009/11/25/comparison-of-rails-deploy...
I am no longer involved in the project, so would not be able to say anything on behalf of the folks who currently taking care of it now.