126.96.36.199 Manager Threads|
CloudTran protects itself again excessive demand by restricting the number of threads that can be used inside the manager.
Each call into the manager to begin and commit transactions, triggered from JPA's transaction.start() and transaction.commit(),
holds a manager cache service worker thread.
There must be enough of these threads to service your maximum expected load.
This number is given by the
To calculate this property, start with the number of JPA transactions you expect to be active at any one time -
from the start of 'begin' to the end of 'commit' - across the whole application. Then simply divide by the number of manager nodes.
managerCacheServiceThreadCount = nJpaTransactions / nManagerNodes
The downside of creating too many manager threads is that it reduces performance,
partly because the sheer number of threads in a machine may add operating system-level overhead,
but more importantly because threads can back up when there are excessive simultaneous cache writes or network traffic.
On a Gigabit network using four-core server machines, with the optimal number of manager threads, CloudTran can commit in approximately 10 ms.
with moderate traffic and 20ms. with maximum load.
When too many manager threads are configured and the transaction managers are overloaded,
overall performance decreases significantly - by as much as a factor of 10.
The downside of creating too few manager threads is that there will be more backoffs at high load.
These are handled within CloudTran and do not cause the transaction to fail, so they are only a minor performance hit
because they make an unsuccessful call from one manager node to another.
Because this impact is small, it is best to allocate slightly too few than too many manager threads.
You will know when there are too few threads because the manager will report
Invoke on cache ManagerControlCache delayed for 20 ms.
where '20' is replaced by the actual delay. If you see more than one or two of these logs in the manager console
and you are looking to improve aggregate throughput,
try increasing the managerCacheServiceThreadCount and see if it helps.
188.8.131.52 Application Threads|
The 'Manager Threads' of the previous paragraph are the worker threads on the ManagerControlCache, which is defined by CloudTran.
The 'Application Threads' described here are the worker threads on the Application cache.
The application caches (also referred to as entity caches because they cache the application's entity objects)
are not defined by CloudTran; they are defined in the application configuration.
However, you must take note of the following CloudTran requirements when defining application caches:
You can change the cache names for the entities and you can even share caches.
This would make sense if you are using the same table to generate IDs.
An example of doing both is below, where the Child uses the Parent table to allocate IDs and shares the Parent cache.