When you evaluate a system with a garbage collector and want to understand its tail latency, you often see SPECjbb2015 or DaCapo used. While both offer corrective measures for coordinated omission, only SPECjbb2015 can run the workload generator and backend server in the same JVM, as well as separate them into different JVMs. This post is a deep dive that uses SPECjbb2015's flexibility to explore and highlight the risks of running the workload generator in the same JVM as the backend.
The Limitations of Running a Workload Generator In the Same JVM as the System-Under-Test
SPECjbb2015 benchmark, garbage collector tail latency, coordinated omission, JVM workload generator isolation, DaCapo benchmarks
Originally published on insidejava
Read also
- Your Load Generator is Probably Lying to You - Take the Red Pill and Find Out Why
- 10 Stack Benchmarking DOs and DON'Ts
- An open-source benchmark suite for microservices and their hardware-software implications for cloud & edge systems
- Microbenchmarking is hard: virtual machine edition
- Performance analysis of cloud applications