12 Toward responsiveness with load and chaos testing

 

This chapter covers

  • Simulating users with Locust
  • Load testing HTTP endpoints with Hey
  • Chaos testing with Pumba
  • Mitigating failures with explicit timeouts, circuit breakers, and caches

We have now covered all the important technical parts of the 10k steps challenge application: how to build web APIs, web applications, and edge services, and how to use databases and perform event-stream processing. By using Vert.x’s asynchronous and reactive programming, we can expect the set of services that form the application to be reactive : scalable as workloads grow and resilient as failures happen.

Are the services that we built actually reactive? Let’s discover that now through testing and experimentation, and see where we can make improvements toward being reactive.

To do that, we will use load testing tools to stress services and measure latencies. We will then add failures using chaos testing tools to see how this impacts the service behaviors, and we will discuss several options for fixing the problems that we identify. You will be able to apply this methodology in your own projects too.

12.1 Initial experiments: Is the performance any good?

12.1.1 Some considerations before load testing

12.1.2 Simulating users with Locust

12.1.3 Load testing the API with Hey

12.2 Let’s do some chaos engineering

12.2.1 Test plan

12.2.2 Chaos testing with Pumba

12.2.3 We are not resilient (yet)

12.3 From “scalable” to “scalable and resilient”

12.3.1 Enforcing timeouts