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 S. 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 K.‘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
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.
That kind of delay is almost certainly not caused by the rails
framework, I would suspect some environment problem or a horrible
coding mistake.
Try running the app on a differnet machine and see if the delay is
still there. That will eliminate or confirm the environmental setup
theory.
So I decide to improve my code,according to Stefan K.‘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
I believe the majority of the time I’ve seen these delays is because of
a resource conflict. Either memory, waiting for a sqlite3 database, or
a resource file lock. It can also come from slow DNS resolving, or back
networking to your MySQL database.
Also try running free -m on your linux box. Could be that your mongrel
processes got moved out of ram and into swap and now are getting moved
back. THis has been discussed a lot on the list about slow “first”
requests.
Is it the first request or all of them? If its all of them then this
is not your issue, if its the first, then this is probably the problem.
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.
Every time I’ve seen this happen, and I’m not talking only about RoR,
it was caused by a badly configured DNS. Either your machine is
probably unable to resolve it’s own hostname, or your webserver is
configured to resolved client’s hostnames, and is unable to do that.
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.
up so slow should be the code of myself.
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.
On Mon, 2006-08-21 at 12:01 -0700, snacktime wrote:
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.
On Tue, 2006-08-22 at 01:39 +0100, Justin F. 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:
[…]
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:
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 –
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.