Rails performance improvement

I'm having similar performance problems with http://scosug.org - a rails site that I just recently had to move quickly into production before having it 100% done.

The site is currently being served up by mongrel 0.3.13.3 (in production mode) and mongrel_cluster 0.2.0, with 3 mongrels behind pen.

The initial load of the site shows a LOT of activity in the status bar of the web browser, but subsequent reloads of the page, or loads of additional pages beyond the opening page of the site, are pretty quick.

Tailing log/production looks like this:

(doing a shift-reload on the browser) Processing WelcomeController#index (for 205.139.10.95 at 2006-08-21 11:52:55) [GET]   Session ID: 19e6e8444e6a82381fc5708b06053c37   Parameters: {"action"=>"index", "controller"=>"welcome"} Rendering within layouts/application Rendering welcome/index Completed in 0.00980 (102 reqs/sec) | Rendering: 0.00771 (78%) | DB: 0.00026 (2%) | 200 OK [http://www.scosug.org/\]

(just clicking reload on the browser) Processing WelcomeController#index (for 205.139.10.95 at 2006-08-21 11:53:18) [GET]   Session ID: 19e6e8444e6a82381fc5708b06053c37   Parameters: {"action"=>"index", "controller"=>"welcome"} Rendering within layouts/application Rendering welcome/index Completed in 0.00974 (102 reqs/sec) | Rendering: 0.00766 (78%) | DB: 0.00029 (2%) | 200 OK [http://www.scosug.org/\]

According to those log entries, it *looks* like everything should be blazing fast, but the actual user experience is totally different.

I did a client-side tcpdump which shows something in the neighborhood of 8 pages of network transactions on a full page load (or shift-reload in the browser) and less than 1 page of transactions for a subsequent load of the page.

Any pointers are greatly appreciated.

According to those log entries, it *looks* like everything should be blazing fast, but the actual user experience is totally different.

I did a client-side tcpdump which shows something in the neighborhood of 8 pages of network transactions on a full page load (or shift-reload in the browser) and less than 1 page of transactions for a subsequent load of the page.

Any pointers are greatly appreciated.

The browser is caching the content. Whatever static content you have such as images are served from the cache on subsequent requests.

I realize that there is browser caching going on. However, it seems like there's a lot more being served up on the initial page load than I would expect. The page itself is very simple. Did you look at the site?

I wonder if it has to do with the non-displayed elements (ajax libraries and whatnot) being loaded up.

I realize that there is browser caching going on. However, it seems like there's a lot more being served up on the initial page load than I would expect. The page itself is very simple. Did you look at the site?

I wonder if it has to do with the non-displayed elements (ajax libraries and whatnot) being loaded up.

What I saw going to your site looks pretty normal for serving everything through mongrel/scgi/fastcgi. The server itself might be a tad slow, but the pattern of requests doesn't look out of whack. You need to map things out so that all the static content doesn't touch mongrel, and mongrel only serves up the dynamic pages. No idea how you do that with pen, I normally use apache. With apache I use mod rewrite so that apache serves up all the .html/.js/.css/.gif, etc.. files directly instead of proxying it through to mongrel. That will make a significant difference on how many mongrel processes you need and how fast the site loads.

Al Gordon wrote:

Hi,several days ago i have posted a topic that my rails application starts up very slowly: After the url has been inputed in the browser's address,the webrick/mongrel console will hold for about 7-10 seconds before the static files such as javascripts and stylesheets start to be downloaded.

Zed Shaw gives me some suggests about the enviroment configuration such as the production mode,differenciating between static files and dynamic content,etc, and i have excluded all of the reason of enviroment configuration and think the reasion of my rails application's starting up so slow should be the code of myself.

So I decide to improve my code,according to Stefan Kaes's "Performance Rails" on railsconf 2006,i start to substitute all the :url=>{:controller=>'article',action=>'list'} to :url => "article/list" and remove all the render_component, but the 7-10 seconds' hold still exists, Can anyone tell that some other possibilities that lead to the horrible wait before application start to response. Thanks

Best Regards.

I'm having similar performance problems with http://scosug.org - a rails site that I just recently had to move quickly into production before having it 100% done.

The site is currently being served up by mongrel 0.3.13.3 (in production mode) and mongrel_cluster 0.2.0, with 3 mongrels behind pen.

The initial load of the site shows a LOT of activity in the status bar of the web browser, but subsequent reloads of the page, or loads of additional pages beyond the opening page of the site, are pretty quick.

Tailing log/production looks like this:

(doing a shift-reload on the browser) Processing WelcomeController#index (for 205.139.10.95 at 2006-08-21 11:52:55) [GET]   Session ID: 19e6e8444e6a82381fc5708b06053c37   Parameters: {"action"=>"index", "controller"=>"welcome"} Rendering within layouts/application Rendering welcome/index Completed in 0.00980 (102 reqs/sec) | Rendering: 0.00771 (78%) | DB: 0.00026 (2%) | 200 OK [http://www.scosug.org/\]

(just clicking reload on the browser) Processing WelcomeController#index (for 205.139.10.95 at 2006-08-21 11:53:18) [GET]   Session ID: 19e6e8444e6a82381fc5708b06053c37   Parameters: {"action"=>"index", "controller"=>"welcome"} Rendering within layouts/application Rendering welcome/index Completed in 0.00974 (102 reqs/sec) | Rendering: 0.00766 (78%) | DB: 0.00029 (2%) | 200 OK [http://www.scosug.org/\]

According to those log entries, it *looks* like everything should be blazing fast, but the actual user experience is totally different.

I did a client-side tcpdump which shows something in the neighborhood of 8 pages of network transactions on a full page load (or shift-reload in the browser) and less than 1 page of transactions for a subsequent load of the page.

Any pointers are greatly appreciated.

Hi Al

Initial load of http://www.scosug.org/ appears to involve 20 HTTP requests, downloading a total of 458,675 bytes of data:

# Result Host URL Body Caching Content-Type User-defined 1 200 scosug.org / 4,447 no-cache text/html 2 200 scosug.org /stylesheets/scaffold.css?1149620092 1,276 text/css 3 200 scosug.org /stylesheets/scosug.css?1151341080 7,373 text/css 4 200 scosug.org /javascripts/tiny_mce/tiny_mce.js?1149612883 136,939 text/javascript 5 200 scosug.org /javascripts/tiny_mce/themes/advanced/editor_template.js 40,217 text/javascript 6 200 scosug.org /javascripts/tiny_mce/langs/en.js 1,650 text/javascript 7 200 scosug.org /javascripts/tiny_mce/themes/advanced/css/editor_ui.css 7,017 text/css 8 200 scosug.org /javascripts/tiny_mce/plugins/contextmenu/editor_plugin.js 11,005 text/javascript 9 200 scosug.org /javascripts/tiny_mce/plugins/paste/editor_plugin.js 9,320 text/javascript 10 200 scosug.org /javascripts/tiny_mce/themes/advanced/langs/en.js 2,862 text/javascript 11 200 scosug.org /javascripts/tiny_mce/plugins/contextmenu/css/contextmenu.css 1,226 text/css 12 200 scosug.org /javascripts/tiny_mce/plugins/paste/langs/en.js 380 text/javascript 13 200 scosug.org /javascripts/prototype.js?1149612776 55,149 text/javascript 14 200 scosug.org /javascripts/effects.js?1149612776 32,871 text/javascript 15 200 scosug.org /javascripts/dragdrop.js?1149612776 29,453 text/javascript 16 200 scosug.org /javascripts/controls.js?1149612776 28,036 text/javascript 17 200 scosug.org /javascripts/application.js?1149612776 148 text/javascript 18 200 scosug.org /images/stephan.jpg 21,416 image/jpeg 19 200 scosug.org /images/scosug-bg.jpg 67,890 image/jpeg 20 200 scosug.org /favicon.ico 0 text/plain; charset=ISO-8859-1

I suggest you don't link all those javascript files to the first page that the user visits!

regards

   Justin

Thanks, Justin. That's useful.

My initial guess before digging deeper into the problem is that it's the tiny_mce js that's so big, and that I should maybe put a conditional in place to make that only load on pages that require it.

Which tool are you using to do get these details, btw?

Thanks for the help.

Al Gordon wrote:

Hi Al

Initial load of http://www.scosug.org/ appears to involve 20 HTTP requests, downloading a total of 458,675 bytes of data:

[...]

I suggest you don't link all those javascript files to the first page that the user visits!

regards

   Justin

Thanks, Justin. That's useful.

My initial guess before digging deeper into the problem is that it's the tiny_mce js that's so big, and that I should maybe put a conditional in place to make that only load on pages that require it.

Which tool are you using to do get these details, btw?

I'm using a laptop running Windows XP, and I used Fiddler:

   Fiddler | Web Debugging Proxy and Troubleshooting Solutions

I could also have used the View Document Size facility in the Firefox Web Developer Tools.

regards

   Justin

For Firefox there’s also the Tamper Data extension which is very nice.

Matt