Fwd: Rails Profiling Logs
Greg Moreno
Here's an interesting analysis on RoR/Ruby performance by Nimrod - a
fellow Pinoy maintaining the Philweavers.net community.
Enjoy!!!
Greg
---------- Forwarded message ----------
From: Nimrod A. Abing <nimrod...@gmail.com>
Date: Jul 17, 2006 6:52 PM
Subject: Rails Profiling Logs
To: greg....@gmail.com
Hi Greg,
I've read your comments concerning my experiences with RoR on your
PhilWeavers.Net article. I put in a couple of replies there but in
case you miss them, here's what I have to say...
WRT my profiling data, I upgraded my VMWare setup recently and I had
to reinstall the Guest OS because the old image got corrupted during
the upgrade process. The profile data was in the disk image.
Anyway, my setup was less than ideal because of the fact that this was
done on the same machine basically. I setup a VMWare virtual machine
and configured it as a web server. I then used Siege
(http://www.joedog.org/JoeDog/Siege) on the "client machine" which in
this case was the Host OS. On the Guest OS, I installed OProfile
patches for Linux as well as the tools for using it
(http://oprofile.sourceforge.net/faq/). It would produce output that
looks something like this http://oprofile.sourceforge.net/examples/
It was a tricky setup but I eventually got it running.
Though it would seem that under a VM setup like this, the results
would be a bit "skewed" or "polluted", the results I got were
consistent: ruby was indeed the cause of the slow response times. Even
with FCGID installed.
A better (though still not under ideal conditions) benchmark can be found here:
http://wiki.rubyonrails.com/rails/pages/Framework+Performance
I think this page is already well known to RoR devs like you :)
I also think including Symfony as a test subject while excluding
CakePHP is a big disservice to PHP. PHP4 and PHP5 are two entirely
different languages using two entirely different scripting engines
(zend and zend2). Symfony is PHP5 only, while CakePHP is basically
PHP4 code with the Object model automagically switching between PHP4
and PHP5 versions depending on what's running it.
As for the other benchmark I point out above, I don't think that the
setup for RoR is optimal. Since the most optimal setup (IMHO) would be
using FCGID instead of proxying requests to lighttpd.
Another thing that bothers me is that the Django setup uses
mod_python, which is really unfair to Ruby since mod_python is a full
Python interpreter embedded in Apache via a DSO module. While the RoR
setup still requires Ruby to be invoked as a separate process via a
fork() syscall.
As for both Python and Ruby beating the crap out of PHP in this
content, I would like to point out that APC has a bug that causes it
to randomly segfault. And I think they neglected to realize that PHP
can re-use database connections (just like in Java connection pools).
So their "High Load" results do not convince me :) Philweavers.net
gets more hits than their benchmark and we have yet to experience an
500 Internal Server Error.
Finally, the reason why I concluded that Ruby is what causes RoR
performance to slide (aside from my test results saying so) is that
Ruby is not able to "cache" bytecode compilation results in the same
way Python does. The first time you run a Python script, the
interpreter checks for the presence of a pre-compiled version (.pyc or
.pyo). If the pre-compiled version is up to date, compilation of the
uncompiled script is never performed and Python uses the compiled
version instead.
By skipping the compilation step in subsequent invocations of the same
script, a significant amount of overhead in parsing and byte-compiling
the script is eliminated. Ruby, AFAIK does not have this feature. The
last time I tried Ruby with a large program, (one I wrote using wxRuby
and Ruby 1.6) I noticed a performance hit during startup. Rewriting
the script using Python and wxPython, the performance hit was only
during the first invocation of the script as expected.
Anyway, I really hope that Ruby will eventually have pre-compilation
in future releases. I would really like to rewrite Philweavers.Net in
RoR even though it's a pain to install and upgrade on a RHEL3 server
:)
--
_nimrod_a_abing_
--
/*- - - - - - - - - - - - - - - - - - - - -
Thinking big, working small
http://www.microisv.com.ph
- - - - - - - - - - - - - - - - - - - - - -*/
Greg Moreno
A follow-up on profiling Rails.
Greg
---------- Forwarded message ----------
From: Nimrod A. Abing <nimrod...@gmail.com>
Date: Jul 18, 2006 5:21 PM
Subject: Re: Rails Profiling Logs
To: Greg Moreno <greg....@gmail.com>
Hi Greg,
Just in case someone flames me over this (I'm sure someone will :D),
it's probably worth telling them that I use several programming
languages myself, *including* Ruby. I'm really not that religious
about using a particular language for all my programming needs. I pick
the language and tools that best suits my needs, even if it means
using *eeew* Microsoft Windows-based tools.
I forgot to include what I think is a good profiling setup for RoR,
PHP, or Python. So here it is:
You need two machines on a LAN, preferrably cross-cabled instead of
connected via hub or router.
Server:
FreeBSD or Linux - very minimal installation, remove all services that
are not necessary to do the test. Enable only Apache and MySQL or
Postgresql.
I am not familiar with any profiling tools for FreeBSD but I'm sure
there's plenty of them out there.
OpenSolaris would be nice but I don't think the usual tools found on
Sun's commercial server products are included with it, but correct me
if I'm wrong about this..
If you choose Linux, you will have the option to install OProfile
kernel patches and tools. Depending on the distribution you use, you
probably need to compile a custom kernel for this.
Client:
Choose any OS. As long as you can run Siege on it.
RoR setup:
Apache2 + mod_fcgid
libfcgi-ruby
If you need to do a comparison with other systems (e.g. CakePHP,
Symfony, Django, TurboGears, Catalyst, Maypole) you need to use
Apache2 for *all* setups. Which is why I never use anything else other
than the above setup for RoR. Anything else (mongrel + lighttpd +
apache mod_proxy_balanced) will pollute the results.
As for why I prefer "cross-cabled" LAN over anything else, it's simply
because it removes the router/hub as a factor in the results.
Note that it does not really matter what kind of processor/memory/disk
type is on the server. All it affects is the time it takes to complete
the test, you can use an old 486 if that's all you have :) But
generally, using more memory is good since it prevents the OS from
swapping out to disk memory. So I recommend about 1GB of memory for
the server at the minimum.
Have fun.
On 7/18/06, Greg Moreno <greg....@gmail.com> wrote:
> Hi Nimrod,
>
> Thank you very much for sharing your analysis. I'm sure other Pinoy
> RoR enthusiasts would be delighted to read your experience.
>
> I will be forwarding this email to the Philippine Ruby group.