[EMAIL PROTECTED] wrote:
On Tue, Aug 17, 2004 at 01:32:23PM -0700, Jim Wilcoxson wrote:
The reason thread pools would be interesting to me personally is to be able to control quality of service better. For example, I may want a pool of 5 threads to handle search engine spidering requests, and a pool of 5 threads to handle PHP requests, 5 threads to handle a
Previously, someone on the list (ah, it was Nathan Folkman) recommended Matt Welsh's SEDA paper:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg07026.html http://www.eecs.harvard.edu/~mdw/papers/mdw-phdthesis.pdf http://www.eecs.harvard.edu/~mdw/proj/seda/
That sort of thing sounds both useful and doable in AOLserver.
Can you tell us how it would be better than the thread pool mechanism which was added to AOLserver 4?
Each addresses different issues. The thread pools are nice in that they give you a way to isolate (by URL I believe?) certain types of activites to particular pools of threads, thus preventing any one paritcular type of activity from utilizing all of the threads. Here's a real world example.
Imagine a single Web Server that serves both an application that does a lot of interaction with a database, and also serves up system status pages and other information. Suppose you have the server configured with a max of 10 connection threads. Now imagine a user comes along and decides to do some sort of degenerate query which takes order minutes. The same user, seeing nothing happening, keeps hitting reload. In fact, he's so eager to see some results that he hits the reload button 10 times. You've now got all 10 of your connection threads busy working on his long running database query. Any user wanting to see the system status would not be able to get to the page since the server is now thread maxed.
Now imagine you've set things up with thread pools. The database tool gets a max of 5, and the system stats page gets a max of 5. Now our over anxious database application user can only tie up a maximum of 5 connection threads working on his database query, leaving up to 5 connection threads for users wishing to see the system stats page.
The SEDA article discusses an approach where you mix a single-threaded event driven piece, in our case it could be the driver thread, with multi-threaded workers, the connection threads. The idea is to avoid having the connection threads, which are relatively precious resources, from sitting around idle waiting on things like I/O. Here's an example that illustrates this.
Imagine you've got an application that pulls in data from many sources via simple Web service calls. The driver thread is busy spinning, accepting requests. A request comes to the Web server. A callback is fired off based on the request URL (or something else in the request). The callback fires off a Web service call. The driver thread spins. Perhaps the driver thread accepts a few more requests. The response from the Web service call is received. The driver thread then hands off the initial request plus the data returned from the Web service call to a connection thread where the rest of your application code executes.
The main point of this approach is to move the I/O events up into the single-threaded driver thread, and to avoid waiting on events in your connection threads. That's roughly the idea at least. ;-)
Hopefully that makes sense?
-- AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
-- AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
