httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <rainer.j...@kippdata.de>
Subject Re: porting from IIS
Date Fri, 25 Jul 2008 12:49:56 GMT
Nick Kew wrote:
> On Fri, 25 Jul 2008 11:06:44 +0300
> "Harold J. Ship" <Harold@giant-steps-networks.com> 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

Mime
View raw message