--- title: OctoPerf 11.7 - Pacing, monitoring, dynatrace and more url: https://blog.octoperf.com/octoperf-117---pacing-monitoring-dynatrace-and-more/ date: '2025-09-30' authors: - gbetaillouloux categories: - Innovation tags: - Dynatrace - Comparison - Reporting - Monitoring - Automation description: OctoPerf 11.7 is available, with new pacing/throughput options, improved load agent monitoring, dynatrace integration and many smaller features --- # OctoPerf 11.7 - Pacing, monitoring, dynatrace and more ## Article Summary OctoPerf 11.7 focuses on more realistic load control, deeper monitoring, and stronger observability integrations. New pacing options make it easier to model user behavior beyond simple concurrency. Load agent monitoring now exposes JVM-level metrics to better detect bottlenecks. Dynatrace integration has been refined for clearer correlation between load tests and APM data. Reporting and runtime controls are improved to simplify comparisons and execution tuning. ## Table of Contents - [Improvements](#improvements) - [Full changelog](#full-changelog) - [Introduction](#introduction) ## Introduction This new release of OctoPerf brings a lot of long awaited features. **This is all based on your feedback**, so make sure to *let us know what you would like to see in OctoPerf next!* Of course we have a few plans of our own for the future, but I strongly believe that **a good software can only result from a good collaboration between users and developers**. ## Improvements ### Pacing your execution #### Throughput If you ever had to execute a load test campaign you are probably aware that **it's not only a question of concurrent users**, you also need to **define the execution rate of each user**. [JMeter](https://jmeter.apache.org/) provides a [Constant throughput timer](https://jmeter.apache.org/usermanual/component_reference.html#Constant_Throughput_Timer) that is also available in OctoPerf, this way you can define a target hit rate and the timer will increase or decrease to try to maintain this rate: ![Throughput](https://blog.octoperf.com/img/blog/octoperf-11-7/throughput.png "Throughput") The main problem with this timer is that it is incompatible with anything that influences sub requests like the [automatic resources](https://api.octoperf.com/doc/design/edit-virtual-user/action-types/http-actions/#download-resources) and [follow redirects](https://api.octoperf.com/doc/design/edit-virtual-user/action-types/http-actions/#follow-redirects) option. It's also often difficult to translate **real business transactions activity** to a certain number of hits/s. #### Pacing But when you come from a load testing background you might also be familiar with [iteration pacing](https://api.octoperf.com/doc/runtime/edit-scenario/edit-user-profile/options/policies/#pacing). The idea is to define a minimum duration for each [iteration](https://api.octoperf.com/doc/runtime/edit-scenario/edit-user-profile/options/policies/#end) and wait until this minimum time has elapsed before moving to the next one. This is not natively available in JMeter but to make matters easier, **we added the option to OctoPerf**: ![Pacing](https://blog.octoperf.com/img/blog/octoperf-11-7/pacing.png "Pacing") This can be combined with [think time override](https://api.octoperf.com/doc/runtime/edit-scenario/edit-user-profile/options/policies/#think-time), but it is mutually exclusive with the throughput option, since both achieve the same goal but with a different method. ### New Load agent monitoring OctoPerf has provided [load agent monitoring](https://blog.octoperf.com/infrastructure-monitoring/) for a while now. It automatically [triggers alerts](https://api.octoperf.com/doc/analysis/edit-bench-report/report-items/monitoring-alarms-table/) when one of the key metrics is over the limit, for instance here with [segments retransmitted](https://en.wikipedia.org/wiki/Retransmission_(data_networks)): ![retransmit](https://blog.octoperf.com/img/blog/octoperf-11-7/retransmit.png) But this monitoring at the [operating system](https://en.wikipedia.org/wiki/Operating_system) level is flawed since it doesn't show what's going on inside JMeter's [Java virtual machine](https://en.wikipedia.org/wiki/Java_virtual_machine). That is why we've added new metrics such as heap memory used: ![heap](https://blog.octoperf.com/img/blog/octoperf-11-7/heap.png) But also a lot of others like [garbage collection](https://en.wikipedia.org/wiki/Garbage_collection_(computer_science)) times and threads. ### Better Dynatrace integration We have also reworked our [Dynatrace](https://www.dynatrace.com/) integration to make its results even more relevant. You can activate it from the runtime screen as usual: ![Activate Dynatrace header](https://blog.octoperf.com/img/blog/octoperf-11-7/activate-dyn-header.png "Activate Dynatrace header") Then each request will have an additional [header](https://api.octoperf.com/doc/design/edit-virtual-user/action-types/http-actions/#request-headers): ![Dynatrace header](https://blog.octoperf.com/img/blog/octoperf-11-7/dyn-header.png "Dynatrace header") All the details about how this header is computed can be found [in our documentation](https://api.octoperf.com/doc/runtime/edit-scenario/integrations-automation/apm/#dynatrace-header). Then in Dynatrace you can capture the values passed in this header this way: ![dynatrace-config](https://blog.octoperf.com/img/blog/octoperf-11-7/dynatrace-config.png) ![dynatrace-config2](https://blog.octoperf.com/img/blog/octoperf-11-7/dynatrace-config2.png) ![dynatrace-config3](https://blog.octoperf.com/img/blog/octoperf-11-7/dynatrace-config3.png) ![dynatrace-config4](https://blog.octoperf.com/img/blog/octoperf-11-7/dynatrace-config4.png) This will give you a much better overview of your load test from inside Dynatrace. And you can correlate it with any other relevant metric during your tests. ### Comparison report labels Previously, when creating a [comparison report](https://api.octoperf.com/doc/analysis/compare-bench-results/) each test result was labeled `Result A`, `Result B`, etc... We've added a new option to **rename the labels** so that you can create even simpler comparison reports: ![compare-labels](https://blog.octoperf.com/img/blog/octoperf-11-7/compare-labels.png) After that all the labels will be updated: ![compare-labels-table](https://blog.octoperf.com/img/blog/octoperf-11-7/compare-labels-table.png) ### Auto resources [Automatic resources](https://api.octoperf.com/doc/design/edit-virtual-user/action-types/http-actions/#download-resources) can be activated from the design screen, on each request. But when you want to change your strategy and deactivate the automatic download of resources, it can be tedious to deactivate it for each request of each virtual user. So instead, we've added the option [on our runtime screen](https://api.octoperf.com/doc/runtime/edit-scenario/edit-user-profile/options/device/#download-resources): ![resources](https://blog.octoperf.com/img/blog/octoperf-11-7/resources.png) You can chose to leave them as they are, or force activate/deactivate them. ### Zipped dataset upload Another important topic is the upload of dataset files, when working with large files and [automation](https://api.octoperf.com/doc/runtime/edit-scenario/integrations-automation/ci-cd/maven/), it can take a lot of bandwidth and/or time to upload the files. We've added a possibility to **upload a group of zipped files** to make that process easier: ![unzipme](https://blog.octoperf.com/img/blog/octoperf-11-7/unzipme.gif) Just make sure your filename ends with `.unzipme.zip` and we will automatically pick it up. ## Full changelog For the complete list of fixed bugs, please refer to [11.7 Release Notes](https://api.octoperf.com/doc/release-notes/#1170-8th-april-2020).