Speed in production mode

Hi,

I've recently been working on a social networking site developed in
Rails. Even though it wasn't very well developed (I only had to do
some minor modifications and most of the code was written back in
2006), I noticed it was a bit on the slow side. Even in production
mode.

Now apart from the fact that it wasn't a lightweight application
(partly due to a lack of optimization in some of the code), it also
had to do with a slow response time from the server and I've noticed
that with a lot of other Rails websites as well. Even with my own apps
(though I work with most of them only in development mode, so that
could also explain why).

I know Rails is thought to be slow. I also know this is due to the
fact that most people consider Ruby to be slow. However, if I'd want
to make sure my apps run as fast as possible (apart from optimizing
the code), what would be the things to consider? We're already running
Apache with mod_rails (Passenger) and Ruby Enterprise Edition after I
looked into it a few months ago. But are there any ways to speed it up
even more? The server I was talking about earlier was running nginx
with Passenger and REE.

Is there more I can do to ensure I at least get my apps running as
fast as possible? (even though it might never be as fast as PHP was
for me)

Thank you.

Is there more I can do to ensure I at least get my apps running as
fast as possible? (even though it might never be as fast as PHP was
for me)

First thing you should do is to measure — profile your app and find
which parts are slow.
Then you may look into the cause of it and what can be done about that.

Regards,
Rimantas

+1 -- guessing doesn't cut it :slight_smile:

One excellent option: <http://newrelic.com/>

Great, thank you both.

However, isn't there a "fastest" setup? Is there any documentation on
whether it's best to go with Passenger/Apache, Passenger/nginx,
Mongrel or something like that? Even the most simple applications are
relatively slow and that shouldn't be.

IMO, no; performance tuning is pretty much always "it depends" :slight_smile:

e.g. Apache vs. nginx? any differences in web server speed may be
irrelevant in the face of poorly indexed DB tables. And the indexes
you need depend on the queries you're making, so...

FWIW,

If the app is slow, how "slow" is slow? 2s a page or 10s for a page?

Now you have to look at what is slow. Is it page render? is it the
database?

If its page render you will have to look at caching.
If its database you need to optimize the database. Add indexes and
tune the database. Are you using MySQL? Innodb? did you change the
tablespace after going live? How but is the database in MB?

I have a feeling that your site does not get crazy amount of traffic
and therefore using nginx or Apache or passenger or thin is not going
to make any difference. UNLESS your server is a virtual server with
only 256mb ram and you are swapping because you did not move the max
passenger threads down from the default 6..

my 2cents...

PS if this app is 3+ years old you should at a minimum upgrade rails
and make use of new rails features... 2006 is Rails 1.1.x ...

If the app is slow, how "slow" is slow? 2s a page or 10s for a page?

Now you have to look at what is slow. Is it page render? is it the
database?

Well, it depends, sometimes rendering takes up 71% of the time,
sometimes just about 40%. The thing is, in the logs I see this a lot:

Completed in 2.24305 (0 reqs/sec) | Rendering: 0.17941 (7%) | DB:
0.15140 (6%)

I don't get that. Especially not because in the same request, I see
this, among other things:

Rendered shared/_something (0.21424)

Now, the 2.2 seconds is way too long and that luckily doesn't happen
too often. But why doesn't the request summary add up?

I have a feeling that your site does not get crazy amount of traffic
and therefore using nginx or Apache or passenger or thin is not going
to make any difference. UNLESS your server is a virtual server with
only 256mb ram and you are swapping because you did not move the max
passenger threads down from the default 6..

It's a big website and I'm not saying it's not optimized, because
that's really where the problem is in this specific situation, but I
also experience high loading times on very small private projects.
I'll go look in the logs there as well.

my 2cents...

PS if this app is 3+ years old you should at a minimum upgrade rails
and make use of new rails features... 2006 is Rails 1.1.x ...

There have been upgrades, we're on 2.1.1 now.

Thank you.

Is the app "overly-eager"?

I ask because I have a compatriot who learned about eager loading, and
shazam! EVERYTHING was eager loaded... even stuff that wasn't needed at
the time.

Lol, I'll look into that, but I don't think this is the problem. And
isn't eager loading data also only loaded when used? Again, I didn't
develop this app, so it might take some time to look at all this (and
it's probably coming out of my own time), so I'm just trying to gather
some general info, also for future applications.

As mentioned before, data is king, so profile to see what the real
hold-up is.

And a +1 for discriminating caching... we knew our sidebar was
computationally busy (displays items related to the primary entity being
shown). That sidebar as a whole is cached, and the individual groups of
related types of items within the sidebar are cached as well. Depending
on the data content, views rendering cached fragments complete in 3% to
10% of the time versus no cached data.

I'll look into caching. I think things like stylesheets and
javascripts are cached, but that doesn't really do anything for the
application, I guess. The navigation can be cached, as it's pretty
static. And the frontpage elements can also be cached, as it's not
personalized and only updates when something new is added (which
happens only once per 40 - 50 requests, I guess). That could help alot!