300 second 'timeout'

Access logs show several 300 second timeouts

[GlenA]

Im not sure where to look, or if this is 'strictly' an apache issue, but here goes...

I have noticed that in the access logs that there are several requests that seem to 'timeout' - hitting the 300second timeout.
(which i guess is - [httpd.apache.org...]
This could be for retrieving a simple gif icon that takes milliseconds, or it could be for a more complicated request that would normally take 6-8seconds - both of these operations happen 100,000's of times without issue during the day.

Does anybody have any idea of how i would possibly begin to troubleshoot what is going on?

The web app has some 10,000 users per day, with millions of requests a day. There are anywhere from 30-300 of these 300second timeouts, and they occur at any time of the day (even at 1am when there are few users).
I have no idea what the user experiences at the browser, as i have never been able to replicate this - and we havent received any complaints....

[lucy24]

The secondary question is easy:

I have no idea what the user experiences at the browser, as i have never been able to replicate this - and we havent received any complaints....

In the case of an image they end up with the same thing their browser shows if the image file is missing in the first place. You've seen those. Timeouts on files get a browser screen that says something like "the operation timed out and the browser has quit trying". Have you really never got one anywhere? Lucky you.

I got a whole slew of them the other day while running the w3c Link Checker locally, because it idiotically thinks the "http://" blahblah in the DTD is a link that needs to be checked. (It's a downloadable text file, but surely w3c knows that already? It's got brains enough to skip mailto: links.)

[GlenA]

ok ok - I know what the user 'should' experience if this happens.

I wasnt clear before - but what makes me suspicious, is that if there were a hundred people a day waiting for 300 seconds for a critical operation (ie: not just a static gif/icon - but the primary contents of the entire page) - then i would be pretty certain that i would have had many complaints about it, and at least 1 error logged with a 'Page could not be displayed' problem...

Therefore, i was more wondering if these are somehow 'orphaned' - and nothing is actually waiting on the response because they have already submitted the request again.... (and yes, i am just rambling/thinking aloud here, and i will go and check to prove/disprove that theory....)

[lucy24]

Oh, wait, I know the kind of thing. Have you ever posted a message to a forum, and waited and waited and waited for the software to do its thing, and finally you get tired of waiting, move on to another tab and there's your post, large as life? There's no delay transferring the information from your end to theirs, there's something preventing the right information from being transmitted back to you.

Matter of fact, 300 seconds -- five minutes -- just doesn't seem possible. The browser itself wouldn't wait that long. (Any idea where they hide the prefs? I looked in two different browsers, the router settings and the system prefs, but couldn't find anything relevant.) I just tried it on a site where I'd previously noted a timeout, and two different browsers cut out after 75 seconds. Not a DNS issue; I tried the raw IP too.

Did you mean the TimeOut directive? Autolinking apparently eats the # fragment.

The timer ... has been lowered to 300 which is still far more than necessary in most situations. It is not set any lower by default because there may still be odd places in the code where the timer is not reset when a packet is sent.

Bingo. We're in "odd places in the code" territory :)