The Bridge - Issue 3, 2021 - 21

Feature
Analyzing Service Mesh Performance
Written in C, wrk2 supports ignoring coordinated
omission and provides tests of more complex scenarios.
Users express load generation profiles in terms of RPS.
Benchmark results may not show what every 1,000th
user might see. To see these outliers, you need to run
the longer (time) performance tests. Wrk2 tests the
scenario where there's a string of services comprising
microservices. Wrk2 requires you to specify the desired
RPS, while wrk does not. Wrk2 is focused on driving the
maximum RPS. Meshery's fork of wrk2 enables testing of
multiple endpoints and enables the variable rate of load
generation. In the future, Meshery will offer the ability
to assign a weight to each endpoint for the load to be
generated by wrk2.
Written in Golang, fortio [9] is extremely fast and usable
for testing basic response times on a per request level.
Fortio produces results in JavaScript Object Notation
(JSON) on a per request basis and easy to integrate into
other Golang-based tooling like Meshery.
Written in C++, Nighthawk supports both open- and
closed- loop testing, and was designed to offer the
right sensitivity for benchmarking microservice proxies
(sub millisecond latencies). Using an open loop test
methodology avoids coordinated omission, and, in
conjunction with its adaptive load controller, one can
seek answers to questions like " what RPS can my mesh
reliably sustain under set latency? " .
It is important to note the power of the service mesh
data plane and the cost of that power. Envoy is a popular
proxy of choice for service mesh data planes. Among
other features, Envoy provides the ability to integrate
custom traffic filters via one of two methods:
* Natively by incorporating your custom traffic filter into
Envoy's C++ source code and compiling a new Envoy
Table 1: Comparison of Types of Data Plame Filtering
Implementation Type
Golang-based Client Library
500 RPS
Unlimited RPS (4,417)
WebAssembly Virtual Machine
(Rust-based Envoy Filter)
100 RPS
500 RPS
Unlimited RPS (5,781)
version. The drawback being that you need to maintain
your own version of Envoy, while the benefit being that
of your custom filter running at native speed.
* Via WASM by incorporating your custom filter
as a WebAssembly binary writing in C++, Rust,
AssemblyScript or Go. The drawback being that WASMbased
filters incur some overhead, while the benefit
being that you can dynamically load and reload WASMbased
filters in Envoy at runtime.
Whether to integrate your traffic filters natively or as an
extension, a tradeoff between the two deployment exists
primarily in exchanging between service mesh speed and
service mesh flexibility as shown in Figure 5.
Figure 5: A comparison of different modes of delivery of service mesh
network functions.
As an assessment of this tradeoff, Table 1 shows an
analysis of two tests run across the same rate limit
network function implemented as 1) a Golang-based
client library or 2) a Rust-based Envoy filter running in
a WebAssembly virtual machine. Users not only need
to account for the (relatively) easy to quantify system
overhead and the operational overhead involved in
expending development resources to implement bespoke
tooling versus managing off-the-shelf filters.
Requests per Second (RPS)
100 RPS
Median Latency p50 (50th Percentile)
3.19 ms
2.44 ms
0.066 ms
2.1 ms
2.22 ms
0.62 ms
HKN.ORG
21
http://www.HKN.ORG
The Bridge - Issue 3, 2021

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