Re: Witango-Talk: threadPoolsize - 5.0.1.065

[John McGowan]

Robert Shubert wrote:
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.
 

Part of the problem is that the application I'm talking about is the 
delivery engine for our Content management system which consists of a 1 
taf and 1 tcf (not used in the proper OO sense, but more of a "library" 
of supporting routines for the taf)

The taf if 45k and the tcf is around 250k   Some sites also require the 
loading of a site specific tcf which contains all the form handling code 
for the site.  Sometimes the homepage is filled with enough 
functionality that the homepage requires the calling of that tcf too.  
The site specific tcf can get quite large.  Either way, this isn't a 
problem with T2K because it wasn't truly multi-threaded.  (but I'm not 
complaining about that! I LIKE the fact that it's truly pre-emptive)

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.
 

Big probem... I don't think i'd call it a big problem.  99% of the time 
the server starts serving up requests very well within a 15 seconds or 
so.  But It has on occasion gotten so out of hand that I've had to 
restart it again to get it going.  (I think this is related to some 
issues with the caching system that will be fixed in 5.5)

As an example on a server with no traffic, the first hit to a page might 
register 3000ms with the @timer tag and 100ms after everything is cached 
nicely.

Obviously if caching wasn't turned on the server could never handle more 
than "hobbyist" type traffic, but with caching on and the cache filled 
up, it runs very nicely serving up pages in less than a second.

So it's hard to argue for a hardware upgrade just to handle those few 
seconds after the cache is cleared.

Luckily for me, the ability to purge just the include files (which our 
CMS uses quite a bit) works in Witango, so when a user of our CMS goes 
to change content on their site, and we programatically clear the cache 
for them we can do it to just the include files so in that case the 
server doesn't come to a halt.  It only happens when I'm doing 
development or pusing new versions to a production server.

/John


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
 

________________________________________________________________________
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf