HostingRails.com

Hi Cilphex,

I am getting the following time while loading your application. Could you please verify this from your end.

=====
Completed in 0.00408 (245 reqs/sec)
=====

It seems like it has taken around .004 seconds to load the application.

Hi Vinayan,

Yes, the main presentation part of my application (-.com) does render that quickly, but that's because it's mostly static data.  Try typing in one of these addresses and seeing what you get in the log:

laceyannphotography.com
cilphex.com
jdmeyerphotography.com
seanbrady.net
etc...

seanbrady.net, for example, gets this for one of its pages:

=====
Completed in 1.68623(0 reqs/sec)
=====

Hi Cilphex,

Please avoid posting account related stuff like domain name, username etc. I got the following logs from the production log while accessing the domain.

for domain.com
====
0.00354 (282 reqs/sec)
====

for domain.com/display

=====
Completed in 0.59346 (1 reqs/sec)
=====

for domain.com/display/flash_info

=====
Completed in 2.17807 (0 reqs/sec)
=====

It seems like due to the flash content in the application the rendering time is increasing.

Hi again,

Thanks, I'll try to remember to refrain from posting domain-specific info in the future.

The Flash content is not the reason that the page is redering slowly.  "Render" means the time it takes Rails to generate the HTML page, not how long the Flash file takes to be transferred to the client's browser.

Indeed, the page that takes longest to load is domain.com/display/flash_info.  But 'flash_info' is just the title of the page, it doesn't actually have any Flash content in it.  In fact, it doesn't even have any HTML content in it--it just generates a text file.  You can see an example by using any of the domains above and appending "/display/flash_info".  It's just a page of variables, that's it.

To tackle the slow rendering time, you may want to look for deeply nested loops or database calls in your views. Please have a look at your code again.

Hi Varun,

I thought something like this might be the problem, that doesn't seem to be the case.  For example, domain.com/display gets the following:

=====
Completed in 0.47998 (2 reqs/sec) | Rendering: 0.26033 (54%) | DB: 0.00000 (0%)
=====

This page uses no loops, and the database calls take very little time (0%).

Is this a consistent problem regardless of RAM/CPU usage on the server?  Its possible that the CPU load could be higher at times which would causes this.  What kind of traffic is this app getting?  Is 2 reqs/sec reasonable for the amount of dynamic hits?  Are you using page caching wherever possible?  Thinking through these will help us figure out if it's a problem with your app, your server, or shared hosting in general for your app based on your deployment setup.  

Hi William,

Yes, this is a consistent problem regardless of RAM/CPU usage.  The app gets low enough traffic that I can open the log and watch it grow on an entry-by-entry basis.  According to Google Analytics, I get less than 1000 page views per day.

I'm not using caching, but I'm not sure how that would work, because the pages generate new content almost every time they're visited.

I don't think it's the server.  I don't see how my app could put that much strain on it, especially with my amount of traffic.  I think it's got to be something with the app, but I have no idea what it could be.

Pages generate new content almost every time they're visited?  Really?  Not that I'm saying that isn't true, but typically most blogs, for example, are cached and then updated when a new post or comment is written to the database.  Often times data on a page does change from external sites (like Google Adsense) but that javascript can still be cached.  

So, while you may be able to apply some of this to your app, another question is what kind of method are you using to deploy (Mongrel or mod_rails or FastCGI?), and if you've tried one of the other to see if the problem persists.  

The way my site works is, user-specific content is rendered based on the domain used to get to the app.  So domain1.com, domain2.com, domain3.com, etc... all use the same models, views and controllers, but display different content.  It isn't uncommon to have 7 different domains visited in the same minute, in which case the same app will be rendering 7 different versions of content.  It isn't really like a blog; it's more like a Facebook or Myspace profile, where each individual user's information updates on occasion, but the same program is used to render each of those profiles one after another when they're visited.  Myspace doesn't render Julie's profile on Tuesday and Mark's profile on Wednesday, it renders probably millions of different profiles per minute.  I'm not really sure how caching would work in that kind of setup.

In any case, I'd imagine typical rails performance is a lot better than 5 reqs/sec for pretty standard data, even without caching, no?

Right now I'm using a Mongrel cluster with 8 processes.  I haven't compared it to anything else, but there's no way I'm going back to FastCGI!  I understand other frameworks may perform better--mod_rails even looks interesting--but there's got to be something wrong with the performance I'm seeing, right?

Yeah - a mongrel in your cluster should serve dynamic data significantly faster that 5 req/sec.  Does that happen even on a freshly restarted mongrel?  I'm curious, have you compared it to Thin ?  just gem install thin and fire up thins instead of mongrels on the same ports and test it out.  It's possible that your app may be written in such a way that thin will outperform.