Re^2: Apache / 30,000 Perl script serving limit

Replies are listed 'Best First'.
Re^3: Apache / 30,000 Perl script serving limit by ig (Vicar) on May 07, 2009 at 03:38 UTC
No, it doesn't. It does tell you that there is a resource unavailable but it doesn't say what resource or why it is unavailable. It may be a per-process resource unavailable because a per-process limit has been exceeded, or it may be some other resource or unavailable for some other reason. Cycling the server processes after some reasonable number of requests will do little to identify what resource or why it is unavailable but it is easy to do and it will either be consistent with expectations or not - just another peice of slightly relevant information that can be added to the puzzle. It is similar to but not exactly the same as a graceful restart of the server, which we already know resets the counter (whatever form the counter to 30,000 takes). update: Thinking of this further, it is odd that the limit would always be reached at exactly 30,000 requests if there is a per-process limit as there are effectively up to 6 server processes running (MaxClients 150 and ThreadsPerChild 25). Unless the 30,000 requests were allocated across the child processes strictly round robin or always to a single process, one would expect to succeed with a variable number of requests until, somewhat randomly, one of the child processes reached its per-process limit, after which one might expect intermittent results until all child processes had reached the limit. This suggests that the resource constraint is per user or system wide, perhaps, rather than per-process.	[reply]

Replies are listed 'Best First'.

Re^3: Apache / 30,000 Perl script serving limit
by ig (Vicar) on May 07, 2009 at 03:38 UTC

No, it doesn't. It does tell you that there is a resource unavailable but it doesn't say what resource or why it is unavailable. It may be a per-process resource unavailable because a per-process limit has been exceeded, or it may be some other resource or unavailable for some other reason.

Cycling the server processes after some reasonable number of requests will do little to identify what resource or why it is unavailable but it is easy to do and it will either be consistent with expectations or not - just another peice of slightly relevant information that can be added to the puzzle. It is similar to but not exactly the same as a graceful restart of the server, which we already know resets the counter (whatever form the counter to 30,000 takes).

update: Thinking of this further, it is odd that the limit would always be reached at exactly 30,000 requests if there is a per-process limit as there are effectively up to 6 server processes running (MaxClients 150 and ThreadsPerChild 25). Unless the 30,000 requests were allocated across the child processes strictly round robin or always to a single process, one would expect to succeed with a variable number of requests until, somewhat randomly, one of the child processes reached its per-process limit, after which one might expect intermittent results until all child processes had reached the limit. This suggests that the resource constraint is per user or system wide, perhaps, rather than per-process.

[reply]