httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Kew <>
Subject Re: porting from IIS
Date Fri, 25 Jul 2008 11:34:35 GMT
On Fri, 25 Jul 2008 11:06:44 +0300
"Harold J. Ship" <> 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

> > So that's a (reverse) proxy architecture.  Apache is happy with
> > that,
> and indeed it's a very common scenario.
> Not exactly a reverse proxy in the usual sense because the other
> server is not a web server. In fact in windows it's another process
> connected using COM. We will probably wrap it with a web interface as
> an interim solution until the other process can also be ported to
> Linux.

OK, communicating with a backend using COM is a job for a module,
which could be a mod_proxy protocol module.  You might want to look 
at how mod_proxy(_balancer) and mod_dbd maintain connection pools.

Nick Kew

Application Development with Apache - the Apache Modules Book

View raw message