John, I can kind of see your point, I do know that there is a hit when the cache is cleared, but I've never found it to be a hassle. My poor cache gets cleared many times a day, probably more than 100, and it can contain many thousands of files at any one time. You should take a look at why it takes so long to reload. Making smaller TAFs and TCFs is a help. Faster, larger cache hard drives or faster network (if that's the case) would also be a place to look. Also note that rebuilding the cache will increase memory and require the reparsing of your TAFs/TCFs.
All in all, however, I'm still surprised that this is a big problem for you. You might want to look at overall server improvements or load-balancing. Robert -----Original Message----- From: John McGowan [mailto:[EMAIL PROTECTED] Sent: Thursday, July 01, 2004 3:39 PM To: [EMAIL PROTECTED] Subject: Re: Witango-Talk: threadPoolsize - 5.0.1.065 On the subject of threads, am i the only one that would love an option on the server to dynamically change the number of threads running on a server. (if it doesn't already exist) 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 ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
