One problem that I run into now that the server is actually threading is that when i restart the server, or clear the cache, there are too many requests coming in and since nothing is cached, performance is terrible until the server has a chance to get going. If the server would only run 1 thread after a restart or a cache purge, then that first hit that causes a shared TCF library to load will load quicker because it doesn't have to share resources with other threads. Instead right now 10 hits are coming in all at once all requiring the loading of uncached app and tcf files. slowing down the server even more.
Excuse this post if it's hard to follow. I don't have time right now to polish it, but wanted to get if off my chest right now...
/John
Robert Shubert wrote:
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
________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
