[EMAIL PROTECTED] wrote:
On Tue, 2004-08-17 at 17:16, Nathan Folkman wrote:
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.
How do you determine how many threads to add to each pool?
Good question, and not one I have a good answer for. Guess the best suggestion I can offer you is make changes based on your application performance. I'd suggest looking at the stats provided by something like "ns_info threads" to see where potential bottle necks are, and to help guide you in determining how many threads you need to partition into seprate thread pools.
Let's say you determine the webserver can process 10 requests concurrently. You could assign 5 threads to each pool.
In this situation, one pool may be idle and the server may have spare capacity, and yet still reject requests get assigned to the other pool.
Alternatively, you could have one pool of 10 threads and classify connections as they are received. You might then specify that both users and admins can max out at 8 conn threads each.
Obviously they can't both have 8 conn threads, so what you're effectively specifying here is that the *other* class of connection gets a minimum of 2 conn threads. The effect is more pronounced the more resource pools you have.
Interesting. Almost sounds like dynamic thread pool allocation based on system usage? Assuming you could configure the thread pools on the fly, I'm sure you could come up with some clever algorithm which used past thread usage data + the current state to figure out how many threads to allocate to each defined thread pool. Not really sure that would buy you anything though.
Suppose the easiest thing to do is monitor and adjust accordingly. It's been my experience that most Web applications experience pretty consist usage patterns. Knowledge of how your applciation functions and how users are using your application should allow you to make a pretty good guess at the optimum configuration.
Also, nothing to do with the SEDA or thread pool approach but looking at the current implementation, it's a little inflexible in that it assigns requests to pools based on URL. This allows you to effectively partition your order checkout, for example. It doesn't let you handle quality of service situations like favouring logged in users over anonymous users, or favouring fat-cat CEOs over common proles... :-)
A flexible callback interface would be nice to have here.
Another good suggestion. You should submit it as a formal RFE with examples of how you'd want to use such an interface.
-- 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.
