2017-04-01 07:50 AEST by Arthur Barrett - If the server has more than 10 users, then the server pool size may need to be larger than 10.

The server pool doesn't need to be 'one for each user' - it may need to be higher, or you may get away with 
lower.  But we could at least issue a warning so that users have somewhere to look.

The cvsmanager could also issue a warning in an 'event'.

The eBook should also discuss the server pool size and offer some recommendations.

e.g. (from what I sent to a customer today)

So our recommended first step is to increase the server pool size.  On the server, start the CVS Suite Server 
control panel, then click the 'change settings' (elevate) button and then go to the 'server settings' tab on the 
elevated control panel.  Increase the server pool size from 10 to 20 or higher.  The 'best' number for the 
server pool size is difficult to judge - I recommend increasing it until the 'connection errors' go away.  If you 
think that is going to be too time consuming and lead to a loss of confidence - start by dramatically 
increasing it, eg: to 80.  There is not a lot of overhead on the server for increasing the server pool (but each 
extra pool process does create a new running process, and uses up several handles and a small amount of 
memory).
 
So what is the server pool?  Old versions of CVS 1.x and CVSNT 2.0.x 'started' a server process as each client 
connects to the server.  This is infinitely scalable, which is nice, but incorporates a 'cost' at each connection.  
Now Linux/Unix generally has a very low cost to 'start' a process.  But Windows (and other operating 
systems) have a very very high cost to 'start' a process.  By 'cost' I'm mostly talking time/CPU cycles.  
Particularly on windows - where there may be anti-virus installed, 'starting' a process from an EXE can take 
seconds.  Couple this with a 'client' like Eclipse which fires off many many many 'small' CVS commands to the 
server - each one of those commands slows down due to the 'cost' of starting the process on the server.   In 
some analysis we did at customer sites - the 'command' was taking less than 50ms to 'run' - but the client 
took 3 seconds to run the command from Eclipse.
 
To improve this - CVSNT 2.8.x uses a 'high performance server service' which maintains a 'pool' of processes 
already started and ready to handle a client request.  There are still some delays when you connect to it, 
because until a client connects the server process doesn't know which protocol DLL and which trigger DLL's 
are required, but overall the delay is a lot lower than what it was.
 
The downside is that it's not infinitely scalable.  As soon as one pool process starts work on a client request, 
the server starts another pool process to replace it.  But, again, on windows that can take up to 2 or 3 
seconds (but typically less than 1 second).  Still - with 120 'users' a pool of 10 processes ant a 'busy' time is 
going to become exhausted at some point, particularly with Eclipse clients who fire off many 'quick' 
commands in a sequence, eg: 'ver' 'rls' (or co), 'status' 'rlog' - just in 'synchronise'.