How to check why page slow?

On Fri, 04 Apr 2008 13:36:27 GMT, "Beauregard T. Shagnasty"
<a.nony.mous (AT) example (DOT) invalid> wrote:

In comp.infosystems.www.authoring.html Geoff Cox wrote:
[Firebug]
I do see the above for 9 requests but thn there is sometimes a delay
of 2 minutes before I can use the page .. it's that bit that I want
to check on and Firebug shows nothing even after the 2 minutes ...?

There must be some software which would show up what is happening?

Will this help, prehaps?

http://www.websiteoptimization.com/services/analyze/

Thanks - that's very useful.

Cheers

Geoff

On Fri, 04 Apr 2008 08:19:50 -0800, Blinky the Shark
<no.spam (AT) box (DOT) invalid> wrote:

Geoff Cox wrote:

On Fri, 04 Apr 2008 10:17:20 GMT, rf <rf (AT) invalid (DOT) com> wrote:

Er. It's actually broken into three, a white bit, a grey bit and a cyan
(teal?) bit.

From what I can determine the white bit is that particular file waiting
for an available connection to the host (as in a TCP/IP socket, assuming
the client only has a few to hand). The grey bit is from posting the
request to receiving the entire object. The teal bit is where they post
the milliseconds.

I do see the above for 9 requests but thn there is sometimes a delay of 2
minutes before I can use the page .. it's that bit that I want to check on
and Firebug shows nothing even after the 2 minutes ...?

There must be some software which would show up what is happening?

You don't happen to be using PHP, there, do you?

Yes - in order to access MySQL ...

Why do you ask?

Cheers

Geoff

On Fri, 04 Apr 2008 14:23:55 -0500, Neil Cherry <njc (AT) cookie (DOT) uucp>
wrote:

["Followup-To:" header set to comp.infosystems.www.authoring.html.]
On Fri, 04 Apr 2008 13:04:00 +0100, Geoff Cox wrote:
On Fri, 04 Apr 2008 10:17:20 GMT, rf <rf (AT) invalid (DOT) com> wrote:

Er. It's actually broken into three, a white bit, a grey bit and a cyan
(teal?) bit.

From what I can determine the white bit is that particular file waiting
for an available connection to the host (as in a TCP/IP socket, assuming
the client only has a few to hand). The grey bit is from posting the
request to receiving the entire object. The teal bit is where they post
the milliseconds.

I do see the above for 9 requests but thn there is sometimes a delay
of 2 minutes before I can use the page .. it's that bit that I want to
check on and Firebug shows nothing even after the 2 minutes ...?

There must be some software which would show up what is happening?

I think either using YSlow -> Components might give you a hint or you
could use something like wireshark (and network sniffer) to see how
long things actually take (you'll need to break out everything by
hand.

Thanks Neil - will follow up on these ..

Cheers

Geoff

On 4/4/2008 4:04 AM, Geoff Cox wrote:

On Fri, 04 Apr 2008 10:17:20 GMT, rf <rf (AT) invalid (DOT) com> wrote:

Er. It's actually broken into three, a white bit, a grey bit and a cyan
(teal?) bit.

From what I can determine the white bit is that particular file waiting
for an available connection to the host (as in a TCP/IP socket, assuming
the client only has a few to hand). The grey bit is from posting the
request to receiving the entire object. The teal bit is where they post
the milliseconds.

I do see the above for 9 requests but thn there is sometimes a delay
of 2 minutes before I can use the page .. it's that bit that I want to
check on and Firebug shows nothing even after the 2 minutes ...?

There must be some software which would show up what is happening?

Cheers

Geoff

--
David Ross
<http://www.rossde.com/>

Have you been using Netscape and now feel abandoned by AOL?
Then use SeaMonkey. Go to <http://www.seamonkey-project.org/>.

On 4/4/2008 4:04 AM, Geoff Cox wrote:

On Fri, 04 Apr 2008 10:17:20 GMT, rf <rf (AT) invalid (DOT) com> wrote:

Er. It's actually broken into three, a white bit, a grey bit and a cyan
(teal?) bit.

From what I can determine the white bit is that particular file waiting
for an available connection to the host (as in a TCP/IP socket, assuming
the client only has a few to hand). The grey bit is from posting the
request to receiving the entire object. The teal bit is where they post
the milliseconds.

I do see the above for 9 requests but thn there is sometimes a delay
of 2 minutes before I can use the page .. it's that bit that I want to
check on and Firebug shows nothing even after the 2 minutes ...?

There must be some software which would show up what is happening?

Cheers

Geoff

[Please excuse the blank reply. I accidentally hit the Send button
before replying.]

The cross-posting indicates you may have some JavaScript in the pages.
Is it possible that the page with the two-minute delay has JavaScript
that accesses the Web server for data or for another JavaScript?

I see an excessive delay -- with my browser freezing even for tabs with
pages from unrelated servers -- on some pages from Vanguard Mutual
Funds. I can avoid the freeze and delay by disabling JavaScript.
However, some Vanguard pages then don't work.

--
David Ross
<http://www.rossde.com/>

Have you been using Netscape and now feel abandoned by AOL?
Then use SeaMonkey. Go to <http://www.seamonkey-project.org/>.

Geoff Cox wrote:

On Fri, 04 Apr 2008 08:19:50 -0800, Blinky the Shark <no.spam (AT) box (DOT) invalid
wrote:

Geoff Cox wrote:

On Fri, 04 Apr 2008 10:17:20 GMT, rf <rf (AT) invalid (DOT) com> wrote:

Er. It's actually broken into three, a white bit, a grey bit and a cyan
(teal?) bit.

From what I can determine the white bit is that particular file waiting
for an available connection to the host (as in a TCP/IP socket,
assuming the client only has a few to hand). The grey bit is from
posting the request to receiving the entire object. The teal bit is
where they post the milliseconds.

I do see the above for 9 requests but thn there is sometimes a delay of
2 minutes before I can use the page .. it's that bit that I want to
check on and Firebug shows nothing even after the 2 minutes ...?

There must be some software which would show up what is happening?

You don't happen to be using PHP, there, do you?

Yes - in order to access MySQL ...

Why do you ask?

Because of your issue and something that happened to me about a year ago.

It's not a short story. Grab a beer.

Every page at the two sites in my sig require PHP. The top few elements
(which I'll loosely call the headers) and all of the footer stuff you
will see repeated on every page are PHP inclusions.

One day, with my last host, it started taking about four minutes do
download a blinkynet page. Any page. And if you go there, you'll see
that because I'm on dialup I'm very careful to not make large pages.
Those should probably average 10 or 12 seconds on a dialup. So four
minutes was just crazy. *I had changed _nothing_ from my end.* And I
noticed that this was happening: it would take a minute and a half or two
minutes for those PHP-delivered elements to render; then the body of the
page would load in a snap, just like the whole page did before this
started happening; then it would take another minute or two for those
*bottom* PHP-delivered elements to show up.

I stress: nothing at all changed from my end. Somehow, PHP was just plain
falling on its ass. Remember, the non-PHP bodies of the pages all
downloaded in an instant or two while the PHP-dependent stuff (still not
many bytes, mind you) just went chugga-chugga for minutes at a time.

Of course I couldn't get it through the thick head of that host that I had
changed nothing. So I had to leave. I moved the same code to a new host
and it worked fine from the git-go, and has ever since.

Well, once - long after I moved - I checked blinkynet and found no PHP
happening. I did live chat with them when I saw that; within a minute -
literally - they said "Try it now", and it was working that fast. They'd
accidentally disabled PHP in some fashion. NO problem: they admitted it
and, like I said, they kicked the right corner of their hardware to have
it functional in the wink of an eye.

So that's why I thought if PHP when you described your issues. I'm not
using any databases at any of my sites, so I'll grant that there are more
things to go wrong with your installation than mine. But your problem
sounded very, very familiar.

My experience was also a good lesson in how much difference a responsive
host can make.


--
Blinky
Killing all posts from Google Groups
The Usenet Improvement Project: http://improve-usenet.org
Blinky: http://blinkynet.net

David E. Ross wrote:

Have you been using Netscape and now feel abandoned by AOL?

Being abandoned by AOL is a *bad* thing?

Then use SeaMonkey. Go to <http://www.seamonkey-project.org/>.

--
Blinky
Killing all posts from Google Groups
The Usenet Improvement Project: http://improve-usenet.org
Blinky: http://blinkynet.net

On Fri, 04 Apr 2008 20:42:53 -0800, Blinky the Shark
<no.spam (AT) box (DOT) invalid> wrote:

You don't happen to be using PHP, there, do you?

Yes - in order to access MySQL ...

Why do you ask?

Because of your issue and something that happened to me about a year ago.

It's not a short story. Grab a beer.

Every page at the two sites in my sig require PHP. The top few elements
(which I'll loosely call the headers) and all of the footer stuff you
will see repeated on every page are PHP inclusions.

One day, with my last host, it started taking about four minutes do
download a blinkynet page. Any page. And if you go there, you'll see
that because I'm on dialup I'm very careful to not make large pages.
Those should probably average 10 or 12 seconds on a dialup. So four
minutes was just crazy. *I had changed _nothing_ from my end.* And I
noticed that this was happening: it would take a minute and a half or two
minutes for those PHP-delivered elements to render; then the body of the
page would load in a snap, just like the whole page did before this
started happening; then it would take another minute or two for those
*bottom* PHP-delivered elements to show up.

I stress: nothing at all changed from my end. Somehow, PHP was just plain
falling on its ass. Remember, the non-PHP bodies of the pages all
downloaded in an instant or two while the PHP-dependent stuff (still not
many bytes, mind you) just went chugga-chugga for minutes at a time.

Of course I couldn't get it through the thick head of that host that I had
changed nothing. So I had to leave. I moved the same code to a new host
and it worked fine from the git-go, and has ever since.

Well, once - long after I moved - I checked blinkynet and found no PHP
happening. I did live chat with them when I saw that; within a minute -
literally - they said "Try it now", and it was working that fast. They'd
accidentally disabled PHP in some fashion. NO problem: they admitted it
and, like I said, they kicked the right corner of their hardware to have
it functional in the wink of an eye.

So that's why I thought if PHP when you described your issues. I'm not
using any databases at any of my sites, so I'll grant that there are more
things to go wrong with your installation than mine. But your problem
sounded very, very familiar.

My experience was also a good lesson in how much difference a responsive
host can make.

I know the feeling re hosting people - I spent hours yesterday with
Webfusion trying and so far failing to password protect a folder. My
older account is on a server which appears to problems - the new
account offers no SSH access, just a control panel which will not
create password protected folders!

You have to create your own .htaccess and .htpasswd files and worse
still encrypt your passwords using web based software on the Net -
this was the hosting people's own advice!

The php is used to add data to MySQL and of course that doesn't happen
until the pages have downloaded ... so I keep looking I guess.

Cheers

Geoff

On Fri, 04 Apr 2008 17:47:39 -0800, "David E. Ross"
<nobody (AT) nowhere (DOT) not> wrote:

[Please excuse the blank reply. I accidentally hit the Send button
before replying.]

David,

No problem and I'm now aware of Seamonkey!

The cross-posting indicates you may have some JavaScript in the pages.
Is it possible that the page with the two-minute delay has JavaScript
that accesses the Web server for data or for another JavaScript?

The JavaScript is for making things appear/disappear and getting
values for Ajax.Updater so I don't think this falls into your
categories ..

Cheers

Geoff

I see an excessive delay -- with my browser freezing even for tabs with
pages from unrelated servers -- on some pages from Vanguard Mutual
Funds. I can avoid the freeze and delay by disabling JavaScript.
However, some Vanguard pages then don't work.