Nick Kew wrote:
On Fri, 25 Jul 2008 11:06:44 +0300
"Harold J. Ship" <[EMAIL PROTECTED]> wrote:
That, on the other hand, sounds like solving a problem that isn't
there. Unless you really need
priority queues, you can just let everything run in parallel.
Well, even a priority queue isn't enough. Suppose there are N threads
for handling requests. If N+M "heavy" requests come in a burst, then
there won't be any way to handle any "light" requests until at least
M+1 "heavy" requests are completed. This would be the same even with a
priority queue.
The Event MPM decouples threads and requests (though it's dealing
with a different issue) ...
I still don't see what you have in mind. If your "heavy jobs" are
being submitted to a batch processing queue, why not say so?
But if they're being processed within the HTTP transaction,
then you're just describing an overloaded server that needs to
limit its load in some way (e.g. absolute number of 'heavies')
and return 503 to clients above that limit. See for example
mod_load_average.
It sounds like they want to have different thread pools for light or
heavy requests in order to enclose exhaustion problems within those
pools. E.g. to many heavy requests should not block handling of light
requests. Of course exhaustion of one of those pools would still make
problems for the requests of the same type.
Think of a not so important report generation feature, that uses long
running requests and more important throughput features using short
running requests. If something gets stuck in the reporting feature, it
will exhaust the threads and block further throughput requests.
I can imagine cases, were the problem ist not only theoretic and a
separation of the pools is arguable in order to limit possible damage
(although it increases overall complexity and you'll need more overall
threads than with a single pool).
If you put a reverse proxy in front and use different backend thread
pools, then the reverse proxy could timeout for heavy requests when the
backend thread pool is exhausted (needs to use a short connect timeout)
and would therefore not get starved itself.
The backends could either be httpd instances or other things (Tomcat
with separate connectors etc.).
Another possibility would be to check the number of httpd threads
working on heavy requests when a new heavy one comes (via the
scoreboard) in and declining the request when a limit is reached. That
would only be OK, if heavy requests are usually rare, so the performance
overhead would not be to much.
Regards,
Rainer
