Sh Cache Microservice Benchmarks

Other documentation for the Sh Cache Microservice can be found on the Sh Cache Microservice product page.

The benchmark was performed using a real Sh Cache Microservice, and simulated network functions. The simulated network functions were run on separate hosts from the Sh Cache Microservice. The network functions (HSS, VoLTE, IP-SM-GW) were simulated to abstract away performance considerations for these functions. A real replicated Cassandra database was used, as simulating this effectively is impractical.

The benchmark was run at the maximum sustainable load level for the SH Cache Microservice node. In this configuration there is no tolerance for node failure, any additional incoming messages will be dropped. To allow for node failure, additional nodes need to be added to provide an acceptable margin (an N+K configuration).

20 minutes of ramp up allows for the cache to reach a steady state. At this point data is expiring from the cache as fast as it is being replaced, due to a custom cache retention period. Additionally, this allows the majority of JIT compilation to occur before full load is reached. The JIT compiler compiles Java bytecode to machinecode, and recompiles code on the fly to take advantage of optimizations not otherwise possible. This dynamic compilation and optimization process takes some time to complete. During the early stages of JIT compilation/optimization, the node cannot process full load. At this point, the node is ready to enter full service.

The tests are run for two hours after reaching full load. Load is not stopped between ramp up and starting the test timer.

For the benchmark we used 5 scenarios representing common requests made to the SH Cache Microservice. The SH Cache Microservice implements a REST API for interaction with VoLTE and IP-SM-GW. All scenarios are written assuming no errors occur, and every request recieves a 200 response. Each of the 5 scenarios were assigned a data pool of 200,000 unique subscribers to ensure that there is a meaningful amount of data to cache.

All machines used for benchmarking are provided by Amazon’s EC2 public cloud. We use exclusively c5.xlarge instances as described here. The c5.xlarge instance type has 4 vCPU (hardware threads) and 8 GiB of ram, with up to 10 Gbps networking. Of particular note here, there are two generations of Intel hardware which may be used for any instance, entirely at Amazon’s discretion.

The Sh Cache Microservice configuration is modified from the out-of-the-box install. Cache lifetimes have been reduced to 20 minutes from 24 hours to allow data to move in and out of the cache during the test. Addresses of the various simulated network elements have been configured as well. Some customization of Rhino and JVM configuration is required to be suitable for the Sh Cache Microservice application. These are detailed below.

The benchmark was run at the maximum sustainable load level for the Sh Cache Microservice. In this configuration there is no tolerance for node failure, any additional incoming messages will be dropped. To allow for node failure, additional nodes need to be added to provide an acceptable margin (an N+K configuration).

The benchmark is run at 700 sessions per second split unevenly across all scenarios. Scenarios are weighted unequally to mimic the GET heavy workload expected of the Sh Cache Microservice. We expect a GET heavy workload, as the TAS does multiple SH GET queries for many call flows. HSS writes (and resulting PUTs/POSTs) are comparatively rare.