# Speed in production mode **URL:** \ **Category:** Rails\ **Created:** [September 12, 2009, 11:18am UTC](https://www.ruby-forum.com/t/speed-in-production-mode/175383 "2009-09-12T11:18:09Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![jhaagmans](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/bc8723/32.png) [@jhaagmans](https://www.ruby-forum.com/u/jhaagmans)\ **Post date:** [September 12, 2009, 11:18am UTC](https://www.ruby-forum.com/t/speed-in-production-mode/175383/1 "2009-09-12T11:18:09Z")
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. ---
**Author:** ![jhaagmans](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/bc8723/32.png) [@jhaagmans](https://www.ruby-forum.com/u/jhaagmans)\ **Post date:** [September 12, 2009, 11:25am UTC](https://www.ruby-forum.com/t/speed-in-production-mode/175383/2 "2009-09-12T11:25:46Z")
> 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 [http://rimantas.com/](http://rimantas.com/) ---
**Author:** ![jhaagmans](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/bc8723/32.png) [@jhaagmans](https://www.ruby-forum.com/u/jhaagmans)\ **Post date:** [September 12, 2009, 5:07pm UTC](https://www.ruby-forum.com/t/speed-in-production-mode/175383/3 "2009-09-12T17:07:33Z")
On Sat, Sep 12, 2009 at 2:23 AM, Rimantas L. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > > Is there more I can do to ensure I at least get my apps running as > > fast as possible? > First thing you should do is to measure — profile your app and find > which parts are slow. +1 – guessing doesn’t cut it 🙂 One excellent option: [http://newrelic.com/](http://newrelic.com/) – Hassan S. ------------------------ removed\_email\_address@domain.invalid twitter: @hassan ---
**Author:** ![jhaagmans](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/bc8723/32.png) [@jhaagmans](https://www.ruby-forum.com/u/jhaagmans)\ **Post date:** [September 12, 2009, 8:56pm UTC](https://www.ruby-forum.com/t/speed-in-production-mode/175383/4 "2009-09-12T20:56:22Z")
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. ---
**Author:** ![jhaagmans](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/bc8723/32.png) [@jhaagmans](https://www.ruby-forum.com/u/jhaagmans)\ **Post date:** [September 12, 2009, 9:23pm UTC](https://www.ruby-forum.com/t/speed-in-production-mode/175383/5 "2009-09-12T21:23:52Z")
On Sat, Sep 12, 2009 at 11:09 AM, jhaagmans [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > However, isn’t there a “fastest” setup? IMO, no; performance tuning is pretty much always “it depends” 🙂 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, Hassan S. ------------------------ removed\_email\_address@domain.invalid twitter: @hassan ---
**Author:** ![jhaagmans](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/bc8723/32.png) [@jhaagmans](https://www.ruby-forum.com/u/jhaagmans)\ **Post date:** [September 12, 2009, 10:21pm UTC](https://www.ruby-forum.com/t/speed-in-production-mode/175383/6 "2009-09-12T22:21:49Z")
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 … ---
**Author:** ![jhaagmans](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/bc8723/32.png) [@jhaagmans](https://www.ruby-forum.com/u/jhaagmans)\ **Post date:** [September 14, 2009, 10:55am UTC](https://www.ruby-forum.com/t/speed-in-production-mode/175383/7 "2009-09-14T10:55:01Z")
> 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. ---
**Author:** ![jhaagmans](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/bc8723/32.png) [@jhaagmans](https://www.ruby-forum.com/u/jhaagmans)\ **Post date:** [September 14, 2009, 3:29pm UTC](https://www.ruby-forum.com/t/speed-in-production-mode/175383/8 "2009-09-14T15:29:23Z")
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. 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. ---
**Author:** ![jhaagmans](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/bc8723/32.png) [@jhaagmans](https://www.ruby-forum.com/u/jhaagmans)\ **Post date:** [September 14, 2009, 9:27pm UTC](https://www.ruby-forum.com/t/speed-in-production-mode/175383/9 "2009-09-14T21:27:51Z")
On 14 sep, 15:29, Ar Chron [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > 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!