Optimizing Performance

👍

Ideal "Balanced" Sidecar Configuration

An ideal Sidecar configuration that balances latency with throughput will be allocated two cores and support four parallel connections.

Performance Tuning

The Sidecar is intended to return responses to the /map endpoint with <2 millisecond latency in 99% of calls as well as a high degree of parallelism. It is designed to work as efficiently as possible on a limited number of processors, but can also handle a larger throughput if given more cores.

Optimize for Latency

If your priority is keeping the latency of Sidecar responses as far below 2ms as possible, match the number of connections to the number of cores. Keeping 3500 requests/sec per CPU up to ten cores is a good rule of thumb.

Optimize for Throughput

If latency is less of a consideration than throughput, support 2x the number of connections as you have cores. Around 9000 requests/sec up to six cores is our suggestion.

Additional Tips

• Pool and reuse TCP connections to the Sidecar’s APIs. The expected response time is significantly shorter than the amount of time required to open a TCP connection, so re-using existing connections (via KeepAlive) is highly encouraged.
• Co-locate the Sidecar to its exchange application counterpart. The same host is ideal, but the Sidecar should minimally run in the same datacenter.

Command Line Output

While the Sidecar may occasionally output useful information to the command line, any output observed is strictly not part of the public APIs for the Sidecar, and should not be relied upon for development.

The one exception to this rule is at startup; if the container is run without the necessary command line arguments, or if there is a major problem with the environment, the container will exit with an appropriate error message logged to STDOUT.