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

Sidecar is intended to return responses to the /map endpoint with a latency <2 milliseconds and 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 below 2 ms, match the number of connections to the number of cores. Keeping 3500 requests/second/CPU with up to ten cores is a good guideline.

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/second, up to six cores is a good guideline.

Additional Tips

• Pool and reuse TCP connections to Sidecar's APIs. The expected response time is significantly shorter than the amount of time required to open a TCP connection, so reusing 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 Sidecar may occasionally output useful information to the command line, any output observed is strictly not part of Sidecar's public APIs, 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.