| You can have as many processing servers and task server threads as you
want. For processing servers you need to make sure you have an
adequate number of processing servers in the processing server pool
to ensure adequate response time. You can use ACMSxp system monitoring
to determine if response times are adequate. Of course the more
processing procedure instances you have, the more system resources you
use. In addition, as you increase the number of processing procedures
database contention will also increase.
I"m not aware of a limit for task server threads either.
For task servers, think of each thread as a user process. Given
that you know the size of the stack for each user thread along with
the number of users you should be able to figure out what is a
reasonable number of users for the box. You can use
ACMSxp system monitoring to find out the average amount of time a user
takes to execute a task. You can also use it to determine the maximum
number of threads active during any one particular time. If the task
server does not have enough threads available to handle the maximum
number of concurrent reuqests then the requests should queue up in the
DCE runtine.
In order to set the value of task server threads and processing server
threads appropriately you have to have a good understanding of the
application and the database being accessed.
If the number of concurrent users is going to exceed the number that
can fit comfortably onto a box then multiple boxes/task servers can
be used. As long as you keep the interface id and selection priority
the same for all duplicate task servers, DCE will randomly select
between the servers.
I believe the documentation does a reasonable job of explaining this
as well.
|
|
Thanks, Roscoe
> You can have as many processing servers and task server threads as you
> want. For processing servers you need to make sure you have an
I am using ACMSxp on WindowsNT 4.0 now.
Does the above apply to ACMSxp on WindowsNT as well?
Regards,
Yasuchika Okubo
|
| This can be a tricky business, involving some trial and error, but fortunately
the statistics gathered by the admin gui can be a tremendous help. The trickest
part is guessing the initial settings.
A task thread is needed for the duration of each RPC from the client. From the
usage profile based on the estimated client response time, the average
interval between client RPCs and the number of active clients, you must estimate
the peak number of active RPCs that can overlap, and set the number of threads
to that figure. Alternativly, you can set the number of threads to the number
of active users at first and then reduce it in steps until you see an impact
on the response time.
You use a different approach for setting the number of proc servers. If you
have too few, queues will build up and impact response time. If you have two
many, you can impact paging, especially if you are short of memory in the first
place, again impacting response time or the database response can deteriorate.
You should gather some useful data to start with. Set the number of processors
for each server type to one. Log on a single user and do 10 to 20 transactions
of each kind with monitoring switched on via TPsystem properties. Remember to
reset all counters to begin with. The average response times you record for
each procedure should then be the ideal targets you want to achieve under load.
You can't do any better than that! By the way, if you find for a given server
that you have some frequently called procs that have short response times
mixed in with some procs that have much longer response times, you should
modify your design to separate out the longer ones into their own proc group -
your current design is sub-optimum, as the frequent short-reponse calls will
get queued up behind the longer ones.
Using your workload pattern, try to calculate the chances of two calls
colliding. If they are small, one process (maybe 2 to play safe) is enough.
If you think frequently four will collide, try setting the number to 6.
If you are running a benchmark with a computer generated work load, you could
start the workload running with the number of procs set to 1 and get a rough
check on the response time using a real client. When it settles, use the gui
to double the number to 2 and see if the response time improves. Keep
doubling again until the response time gets worse. You now have a good
idea what the number should be. The number will be very small compared with
the number of users.
If you do this, please let us know the following:
the hardware configuration - processor speed , number of processors
size of memory, number of disk drives, the number of simultaneous users,
the average transaction rate and the optimum number of servers.
This would be a very useful data point.
Good luck!!
|