Performance test version of the Spring PetClinic Sample Application

This project is forked from and extends spring-petclinic/spring-petclinic-microservices.

It serves as an automated performance test environment:

• We use Zikpin to derive software traces and monitor application performance.
• We use Telegraf to derive system traces and monitor system performance.
• We use Apache JMeter to generate load on the PetClinic and execute performance tests.

Please have a look at the original README for general instructions.

Modifications and extensions

We modified and extended the distributed version of the PetClinic in several ways as shown in the following and described below:

Collecting software traces using Zipkin and Apache Kafka

We instrumented the API Gateway, Vets Service, Customers Service and Visits Service, so they send Zikpin traces to an Apache Kafka topic called pg-traces-software. In line with this, we adapted Zipkin collector to use Kafka, which is part of Docker Compose.

This allows us to consume traces for further stream processing in a comfortable way.

Collecting system traces using Telegraf and Apache Kafka

We added Telegraf to Docker Compose.

Telegraf monitors cpu, disk, disk IO, kernel, mem, processes, swap, and system metrics of the entire docker host (see configuration file telegraf.conf). The collected metrics are sent to an Apache Kafka topic called pg-traces-system.

Performance load testing using Apache JMeter

We added Apache JMeter to Docker Compose in order to generate requests and execute performance tests.

The test plan for the dockerized JMeter is located at jmeter/petclinic_test_plan.jmx (it is adapted from spring-petclinic-api-gateway/src/test/jmeter/petclinic_test_plan.jmx). It will be started automatically using the profile load-test (see Run the PetClinic). An output csv file we be stored at jmeter/test-output.csv. If you want to open and change the JMeter test plan, please make sure to install the Concurrency Thread Group plugin.

Provoking performance degradations

We use this project mainly to generate performance traces and provoke different performance bottlenecks. For this purpose, we implemented two scenarios - one memory leak and one cpu hog. Branch apm/degradation/memory-leak leaks memory in the Customers Serivce and branch apm/degradation/cpu-hog hogs cpu in the API Gateway. If you use perform load testing, you should be able to monitor the performance degradations over time.

Updating Docker Compose

We added Apache Kafka to Docker Compose as described above and adapted corresponding configurations.

We added profiles with Compose. This prevents the need to start all services such as Grafana and Prometheus by default, which may not be required, and demands less resources.

We added Kafdrop to Compose to provide a point-and-click way of examining Kafka broker topics and messages at http://localhost:9000.

Run the PetClinic

The easiest way to run the project is to use Docker Compose.

Please make sure to have the following technologies installed:

• Java / JDK (e.g., AdoptOpenJDK)
• Docker (>= 3.2 to support profiles)

Build the required Docker images by running the following:

./mvnw clean install -P buildDocker

To start all default containers, run of the following command:

docker-compose up

Alternatively, use profiles with Compose to start additional containers:

• docker-compose --profile debug up starts Spring Boot Admin, Grafana, Prometheus and Kafdrop
• docker-compose --profile load-test up starts a load test using Apache JMeter

To stop and remove everything, we recommend using the following command to prevent future errors with Apache Kafka:

docker-compose rm -sfv

Contributors of this fork

Georg Neugschwandtner

Anastasios Kalogeropoulos

Johannes Kross