The Bridge - Issue 3, 2021 - 18

Feature
Analyzing Service Mesh Performance
LOAD GENERATORS TYPES
* hardware or software based, L2-3, L4-7, open or
closed loop.
SERVICE MESH TYPES (The Service Mesh Landscape
has over twenty meshes listed [7]. Each share a common
architecture, however, their implementation differs and
consequently, so does their performance.)
* Control plane - often a point of contention the larger
the service mesh deployment is.
* Data plane - not only proxies, but filters loaded in
those proxies.
SERVICE MESH CONFIGURATION AND NUMBER
OF SERVICES ON THE MESH
* Telemetry
- Including the three pillars of observability are
traces, logs, and metrics.
- The number of, cardinality of, sampling rate, ingest
rate... all bear weight (and bear load on the
system).
* Policy
- Authentication, Authorization - frequency of checks,
cache hits versus cache misses.
* Security
- Encryption - overhead of handshaking and
mutually authenticated TLS.
Figure 1: Performance considerations for testing a service mesh
IV. SERVICE MESH PERFORMANCE
AS A SPECIFICATION
The need for cross-project, apple-to-apple comparisons
are also desired in order to facilitate a comparison of
behavioral differences between service meshes and
which one might be best-suited for specific workloads.
THE BRIDGE
Individual service mesh projects shy from publishing test
results of other, competing service mesh projects. The
need for an independent, unbiased, credible, standard
measurement is one of the catalysts for the creation of
Service Mesh Performance (SMP) [6]. The SMP standard
is a specification and a means to disseminate insights
and research results. The authors are working toward the
definition of MeshMark, a universal performance index
to gauge your mesh's efficiency against deployments in
other organizations' environments.
Many performance benchmarks are limited to single
instance load generation (single pod load generator).
This limits the amount of traffic that can be generated
to the output of the single machine that the benchmark
tool runs on in or out of a cluster. Overcoming this
limitation would allow for more flexible and robust testing.
Distributed load testing in parallel poses a challenge when
merging results without losing the precision we need to
gain insight into the high tail percentiles. Distributed load
testing offers insight into system behaviors that arguably
more accurately represent real-world behaviors of services
under load as that load comes from any number of
sources.
The specification itself provides a standard format for
describing and capturing:
* performance test configuration,
* service mesh configuration,
* environment configuration,
* workload configuration,
* performance test results,
* distributed performance modeling,
* key performance indicators (KPIs), and
* test tool requirements.
Value from a service mesh is best derived when it is
tuned to scale as per the deployment requirements.
Given the complexity of deploying, testing and measuring
performance aspects across multiple dimensions, the
specification aims to provide a simple starting point for
anyone looking to understand and derive service mesh
performance. The SMP standard aims to articulate these
complexities in a methodical and automated manner in
order for anyone to plan the performance scenarios of
their deployment and execute relevant tests.
Figure 2 provides insight to the fact that the specification
defines a common collection of statistical analysis to be
calculated for every performance test.
https://hkn.ieee.org/
The Bridge - Issue 3, 2021

Table of Contents for the Digital Edition of The Bridge - Issue 3, 2021
