If the default behavior of the EMS server cannot provide the required throughput and the EMS server machine has multiple cores, you can assign specific cores to the EMS threads that handle network traffic and stores.
For instance, with a 4-core machine, you can use the processor_ids parameter to assign core 0 and core 1 to handle network traffic. You can also use the store configuration
processor_id parameter to assign core 2 to handle the
$sys.failsafe store. This configuration causes the EMS server to create two threads that handle network traffic, and sets the affinity of them to core 0 and core 1 respectively. It also sets the affinity of the thread handling the store
$sys.failsafe to core 2. No affinity is set for other threads.
When the EMS server does not set thread affinity, the operating system can better schedule EMS server threads to react to changing workloads on the machine. Also examine if the application is making efficient use of the API before changing the default behavior. For example, when performing persistent messaging operations, consider using multiple threads in the applications (each with its own session) or consider using local transactions to batch sends and acknowledgements.
When a client connects to the EMS server, the EMS server assigns it to one of the threads handling network traffic based on which of those threads have the fewest existing connections. This balances the total number of connections evenly across those threads.
Also note that the EMS server does not account for the traffic generated by those connections. For instance, the EMS server could assign ten connections to one thread and ten connections to another thread but still have an unbalanced state if the first ten connections account for 90% of all network traffic to the EMS server.