I agree with your sentiments, and it is much as I have learned in my testing. Back when W5 was in beta testing I used to load a server with 100 threads to hunt down bugs.
You're right that your database must always keep up with (better yet, be a step ahead) of your Witango server. You are also correct in that adding threads adds overhead. That's why I ran with 10 thread for a very long time, and only recently up'd to 15. Your points about NT4 vs. Win2K are also very true and memory is a must-have for Witango (as any server). Witango itself does have a parsing and thread management system, and there is also the client, which can hold and process requests. This is more notable on load-balanced systems, where the client has a much more active role in the processing. Simultaneity is a very important metric for any server, and a very hard one to come to terms with. It's something I constantly study in my own environment. Robert -----Original Message----- From: Bill Downall [mailto:[EMAIL PROTECTED] Sent: Thursday, July 01, 2004 1:18 PM To: [EMAIL PROTECTED] Subject: RE: Witango-Talk: threadPoolsize - 5.0.1.065 Robert, I'm one of those whom Chuck calls his "esteemed colleagues." We were all surprised that reducing the threadpoolsize actually aided throughput and stability on our test server, that we were intentionally handing difficult tasks to. Part of our own results were due to that fact that our test server had a limited amount of physical memory (500 Meg). Here are some tidbits that we have learned: For every increase in your threadpoolsize limit count, you are increasing the amount of resources needed for at least three different processes or services. The database engine processes the request, Witango to process the results of the request, I'm not sure what the third "queue" is, it might be the web server, or some service that handles communications between those other things. But according to Phil, there are at least three queues and a triple memory-hit being managed for the http requests coming in. If you have too many threads, and too many huge requests, you can overwhelm the available memory on your system and force the operating system to do a lot of page swapping. A smaller number of threads helped us greatly with the throughput, because Witango server was much better able to manage the queuing and throughput, and wasn't interrupted by frequent thrashing paging processes. We also learned that Win NT 4.0 is no longer a healthy platform for Witango. It does not handle threading as well as W2K and W2K3. 500 Meg is also a very small amount of memory for a web server/Witango server/ database server platform. Bill On 1 Jul 2004 at 12:42, Robert Shubert wrote: > My own ~reasonable limitT for the threadpool is 15 " the default. I > started with 10, and saw that there were times when 11-15 threads > would be used by my users, so I increased it to 15. I suspect that > should my sites get busier, I would need to go to 20. I would not go > above 25, but rather look to adding more servers/services. Typically > my max threads is around 10 now. I have one service at 9 after 3 days > of uptime. Since the max number of active threads since service > inception is a measurement you can get from @serverstatus, I like to > regularly monitor that value to see what ITm using. ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
