This is an update in this problem and a thank you to Daniel. I have been playing with the sub-parameters to the RequestReadTimeout parameter in periods of a couple of days. What I have found is: 1. 408's tend to cluster on particular IP addresses 2. the IP getting the most 408's will come and go, that is, sometimes they have a lot of them and then they disappear from the 408 list even though still about as active 3. it is possible to find sub-parameter values that minimize the 408 rate for a while but then it comes back again for no apparent reason 4. all of the above happens while (many) other users are having no problem at all 5. there doesn't appear to be a "solution" except to live with it I suspect that some inter-ISP connections may be slow, given the ISP's tendency to optimize their own traffic at the expense of other ISP's traffic. Occasionally a connection gets a series of 408's on the same request and then just goes away. Since these requests are all automatically generated by an AJAX process in the browser I would have to assume that the path has got very slow and then gone away completely. On average, only less than 1:2000 requests get a 408 and most clear after the first or second one or else become a cluster. Regards, John ====================================== On Monday 04 June 2012 21:21:32 Daniel Ruggeri wrote: > On 6/4/2012 3:13 PM, John Iliffe wrote: > > 1) since almost all of these 408's are METHOD=GET why is the request > > not present as soon as the initial connection arrives since the > > request is coded in the URL and not in a separate header? The total > > (URL + request) length is about 80 bytes or less. > > Headers are also sent as part of the request. > > > 2) what is the default value when the directive is not present and is > > it reasonable? ie, do I have some as yet undetected problem here? > > This is documented here: > http://httpd.apache.org/docs/2.4/mod/mod_reqtimeout.html#requestreadtime > out > > |header=20-40,MinRate=500 body=20,MinRate=500| > | > > 3) how far should I extend the body= time before I create the problem > > that the directive was designed to resolve - denial of service > > attacks caused by missing requests. > > That's tough to say - the directive exists to limit the amount of > resources a single client can take up by being slow. It really depends > per site as some sites may not be particularly bothered by slow clients > or may not have many. It also varies because some sites serve clients > across the world on very slow connections so they may need to tweak the > values to accommodate those users. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|