The above diagram shows ClayCentral's threading system:

• Multiple connections access the ClayCentral main thread and requests are added to buffers and queues for handling. This includes a queue for Automation events generated by the requests.

• A thread pool handles requests by retrieving waiting requests from the queue. The thread pool is separated from the incoming connections so that a fixed amount of threads are always running to handle any amount of requests/connections.

• The thread pool handles queued requests in FIFO mode. Multiple requests from the same user are generally queued until the last request from the same user is completed so that one user can't hog all the threads.

• Each thread in the pool manages its own database connection.

• Automation events are handled in a separate background thread that is run on a lower priority than the other threads. This thread also manages its own database connection.

Note that since the thread pool is not dynamic and has no relation to the amount of users in the system, a database license can be purchased that only takes into account the thread pool amount plus three additional connections for the Automation and System threads.

To adjust the amount of threads in the thread pool, go to ClayStudio/Administration/ClayCentral Settings and change the Maximum Threads setting. The default value is 4. When adjusting this value, keep in mind the following important issues:

• More threads does not mean better performance. It means that more requests will be handled concurrently, all of which may be sharing resources (database locks, network card, CPU, hard disk, etc), which may cause more conflicts or slow-downs due to constant task switching.

• Other factors that affect performance: Whether other heavy processes are running on the same machine, the average request duration, whether the request includes a database query or use of database locks, the amount of CPUs, the amount of data returned to the client, whether there are many Automation events that are constantly running, etc.

• As a recommended starting point, the value should be minimum 3, or 1-2 over the number of CPUs. For example on a quad CPU system, it can be raised to 5. Additionally, if a quad-CPU system is running with SQL Server on a separate physical machine, then 10 threads is potentially optimal.

• If ClayCentral is connected to SQL Server on another machine, increasing the amount of threads can help performance since the workload is distributed on two machines and while one thread is waiting for query results, another may process another request quickly.

• If using an MDB database, keep in mind that concurrent requests may clash VERY frequently due to table-level locking. In this case, it may help to decrease the amount of threads.

• To test whether performance is increasing or decreasing, use the System Statistics.