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:

   http://www.fiddlertool.com/fiddler/

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