httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Harold J. Ship" <>
Subject RE: porting from IIS
Date Fri, 25 Jul 2008 08:06:44 GMT
>> How it works today: there are 3 types of request: light, medium and 
>> heavy.
>> We will need 2 "pools" of threads. One for handling light requests, 
>> and one for medium/heavy.

> That sounds rather like a new MPM.

>> The light requests can be dealt with by the usual mechanism.
>> The medium and heavy requests should be passed by the to the other 
>> thread pool, freeing the original "ordinary" thread to handle more 
>> incoming requests.

> 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.

If we can pass the heavies to another pool, they can take as long as
they need while incoming light requests are still serviced. Anyway, it
is a constraint already in place in the IIS application. We are simply
porting it.

>> We are worried that if we try to process the medium and heavy
>> with a thread pool, then either the "ordinary" thread will block 
>> anyway, or the next filter will get starved.

> Hmm?  Why do you suppose that?

Well, I don't "suppose" it so much as I just don't know enough about how
it works. For instance, I know that a filter reads its data in chunks
from a previous filter, and writes its data in chunks to the next filter
in the chain.  Is the next filter waiting, in the original thread, for
data from the content generator?

Most of our processing will be in the content generation hook. Will the
"gzip" or other filter block one of apache's threads while we generate
the content in another thread?

By the way, we've ordered "The Apache Modules Book" from Amazon but it
won't be here for another 3 weeks and we need to work now. We are trying
to get by with articles and examples we find on the internet, including

>> The heavy requests mentioned above are to be sent to another server.

> 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.

But essentially, you're right. And perhaps we can take advantage of
Apache's mod_proxy to do it. By the way, what happens with Apache's
thread after mod_proxy has forwarded the request until it receives a

Nick Kew

Application Development with Apache - the Apache Modules Book

View raw message