>> 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 requests >> 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 yours. >> 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 response? -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
