Thread-Per-Core (TPC)
Enable Thread-Per-Core (TPC) on both clients and cluster members to improve system performance. This is especially effective if the number of CPU cores on your machines does not match the recommended hardware in the Production Checklist (that is, either fewer or more cores than recommended).
What is Thread-Per-Core (TPC)?
The threading model is responsible for networking, storage and compute, which means it has a big impact on system performance. With Staged Event-Driven Architecture (SEDA) you have dedicated threads that do one particular task (for example, reading from a socket or evaluating a map.get) and thread pools that manage these threads.
SEDA can lead to throughput and latency issues on machines with limited cores (fewer than 8), as the frequent context switching and state sharing can add significant overhead. Conversely, on machines with a very high number of CPUs (more than 32), a bottleneck can be created by the limited number of I/O threads vs. operation threads. Typically, smaller servers are more commonly used through virtualization and for cloud-specific workloads, which can limit system performance in a SEDA environment.
A Thread-Per-Core (TPC) design uses one thread for every CPU core and every thread does everything. With each TPC thread able to do networking/storage/compute, scaling is mostly a case of increasing the number of threads to spread the work. This means the system can more easily scale up and down based on the number of available cores, and make more efficient use of resources on machines with either a low or high number of cores. Every task is non-blocking, which makes it easier to scale vertically, and results in high throughput, low latency and significantly improved system performance.
When TPC is enabled, clients using the ALL_MEMBERS cluster routing mode connect to the number of cores specified in the client config. If TPC is enabled on both client and server, clients connect directly to one of the TPC threads instead of using the legacy network threads. TPC-enabled servers continue to use the same ports for discovery, which means there’s no difference in how the cluster member list is created and TPC-aware servers are backward compatible with clients that don’t use TPC.
Clients using the SINGLE_MEMBER or MULTI_MEMBER cluster routing modes cannot use TPC. Your clients must use the ALL_MEMBERS cluster routing mode with TPC. For further information on the ClientTpcConfig class used to specify the number of cores to use for connections, refer to Class ClientTpcConfig in the Java API documentation.
|
Configuration Options
TPC is disabled by default and must be enabled on each cluster member and client.
| If you configure a client with TPC and the server doesn’t support it, or if you configure a client without TPC and the server supports it, TPC is ignored in both cases (server and client can still communicate). |
| For example configuration files (XML and YAML) with TPC enabled, see Member Configuration Files. |
Enabling TPC on Members
To enable TPC on a Hazelcast cluster member, you need to set the tpc system property to true as follows:
-
Using the following command:
-Dhazelcast.internal.tpc.enabled=true -
Updating your configuration file with the following:
| 1 | The eventloop-count property sets a maximum number of eventloops (an eventloop is essentially a loop that processes events; normally you have one-per-core). This defaults to the number of available CPU cores, assuming your license supports that number of eventloops (license limit overrides the value). In environments with a very large number of cores, reducing the eventloop-count can increase performance due to better batching and less packet-processing overhead. |
