Continuous Integration and Continuous Deployment
Identifying Performance Changes Using Peass
Performance is a crucial property of software for both closed and open source software. Assuring that performance requirements are met in the CI process using benchmarks or load tests requires heavy manual effort for benchmark and load test specification. Unit tests often cover a big share of the use cases of a software and are maintained anyway. While they have some downsides for measuring the performance, e.g. since they test corner cases or use functional utilities like mocks, they still are a way of measuring realistic use cases with nearly no manual effort.
Therefore, we develop the tool Peass (https://github.com/DaGeRe/peass), which transforms unit tests into performance unit tests and measures their performance. The stand-alone tool Peass can be integrated into the CI-process using Peass-CI, which makes it possible to run performance tests with every build in Jenkins.
The talk starts by introducing the basic idea of Peass.
Then, the steps of the current prototype of Peass are presented:
- a regression test selection, which prunes all unit tests that can not have a performance change by comparison of the execution traces of the same unit tests in two software versions and the source code of the called methods,
- a measurement method, which repeats VM starts and measurement iterations inside the VM until the performance change can be statistically reliably detected and
- a root cause analysis, which identified the node of the call tree which causes a performance change by measurement of individual nodes.
Finally, the talk demonstrates the usage of Peass in a running Jenkins instance.
Additional information
| Type | devroom |
|---|
More sessions
| 2/7/21 |
Introduction of the CI/CD devroom
|
| 2/7/21 |
The emergence of virtualization, containers, and cloud native has resulted in tremendous advances in enabling organizations to develop new services and make them available to end users. In addition, new paradigms such as Continuous Integration (CI) and Continuous Delivery (CD) allow organisations to do this much faster than before, empowering them to go to market ahead of the competition. Despite its many advantages, the CI/CD ecosystem has its challenges. This session will discuss issues ...
|
| 2/7/21 |
Three phrases keep popping up when talking about modern workflows and development and deployment techniques; CD, GitOps, and progressive delivery.
|
| 2/7/21 |
Continuous integration and deployment (CI/CD) system are hardly ever ceaseless as the name would suggest; they do aim though to follow changes in code, configurations and versions. They often achieve that by both handling and generating events. For instance, a CD system receives an event that describes a new version of an application, and it runs a workflow in response. When the workflow starts or when it reaches completion, the CD system generates events for the benefit of other processes that ...
|
| 2/7/21 |
Recently, the MariaDB Foundation has been developing a new continuous integration framework for the MariaDB Server. The goal of buildbot.mariadb.org is to ensure that each change is properly tested on all supported platforms and operating systems. Our new CI uses almost exclusively latent workers, more exactly Docker latent workers. In this talk, I will present a main overview of the CI infrastructure, the advantages of using latent workers and talk about the challenges that we encountered along ...
|
| 2/7/21 |
When Everything as Code converges to automate/test your processes, in this talk we would like to discuss further our journey and our vision to handle our automation programmatically.
|
| 2/7/21 |
Kubernetes, GitOps, and Infrastructure as Code are as powerful as they are popular and seem like the perfect match. Consequently, using Terraform to maintain Kubernetes clusters and resources is a very common use-case. And it requires careful integration of many moving parts, from Terraform providers and modules, to CI/CD pipelines and triggers. However, despite this being such a popular use-case, teams previously had no alternative than writing everything from scratch. On the software ...
|
