> OctoPerf load testing - Application Performance Management documentation page. How to configure a Application Performance Management in OctoPerf.

Source: https://api.octoperf.com/doc/runtime/edit-scenario/integrations-automation/apm/

# Application Performance Management

These integrations are shared with the entire project: you don't need to configure them for each scenario.

## Configuration

![APM configuration](https://api.octoperf.com/doc/runtime/edit-scenario/integrations-automation/img/application-performance-management-panel.png "APM configuration")

### Activate an HTTP Header integration

The following procedure explains how to activate an integration:

1. Oepn the _Application Performance Management_ panel,
2. Click on the checkbox of the integration you want to activate,
3. Close the configuration panel.


OctoPerf currently supports the following APM solutions:

* [Dynatrace](https://www.dynatrace.com/support/help/setup-and-configuration/test-automation/dynatrace-and-load-testing-tools-integration#tag-tests-with-http-headers)
* [App Dynamics](https://docs.appdynamics.com/display/PRO43/Correlate+Business+Transactions+for+Browser+RUM),
* And [Instana](https://docs.instana.io/releases/notes/build_128/#capturing-custom-http-headers).

!!! note
    The additionnal header added by OctoPerf needs to be interpreted on the APM's side, usually by activating the RUM (Real User Monitoring) functionnality.

To understand why your APM and OctoPerf report different response times for the same requests, see [Why response times differ between OctoPerf and your APM](https://api.octoperf.com/doc/analysis/tips/#why-response-times-differ-between-octoperf-and-your-apm).

### AppDynamics Header

When the APM integration is activated from the runtime screen, script validations will also include the header:

![AppD header](https://api.octoperf.com/doc/runtime/edit-scenario/img/appd-header.png "AppD header")

In this case the header sent is `AppD_Header: Buyer.Login_process.01_-_Home_page.Home`
As you can see it is composed of:

- The virtual user name,
- The name of each parent element in their order of appearance,
- The name of the request or its path if name is empty.

### Dynatrace Header

When the APM integration is activated from the runtime screen, script validations will also include the header:

![Dynatrace header](https://api.octoperf.com/doc/runtime/edit-scenario/img/dyn-header.png "Dynatrace header")

The value in this situation is: `VU=lizette_walker-Buyer-1;SI=OctoPerf;TSN=01+-+Prehome;LSN=Buyer;LTN=Check bbXCU3EBE0n4YfPTqrI-;PC=My-request-name`

- `VU` is the unique Id of the current virtual user, made of `agent name` - `virtual user name` - `number`
- `SI` is the name of the load testing tool, `OctoPerf` in our case,
- `TSN` is the name of parent transaction (if any found),
- `LSN` is the name of the virtual user,
- `LTN` is the name of the scenario being run,
- `PC` is the name of the http request or its path.

In `Dynatrace` you can configure these *metadatas* with *requests attributes* like this:

![Dynatrace config](https://api.octoperf.com/doc/runtime/edit-scenario/img/dynatrace-config.png "Dynatrace config")

For example this is how you can get the virtual user name stored inside the `LSN` key:

![Dynatrace config](https://api.octoperf.com/doc/runtime/edit-scenario/img/dynatrace-config2.png "Dynatrace config")

![Dynatrace config](https://api.octoperf.com/doc/runtime/edit-scenario/img/dynatrace-config3.png "Dynatrace config")

![Dynatrace config](https://api.octoperf.com/doc/runtime/edit-scenario/img/dynatrace-config4.png "Dynatrace config")

### Instana Header

![Instana header](https://api.octoperf.com/doc/runtime/edit-scenario/img/instana-header.png "Instana header")


When the APM integration is activated from the runtime screen, script validations will also include the header. 

The following HTTP headers are included within each http request:

- `x-octoperf-testName`: name of the [scenario](https://api.octoperf.com/doc/runtime/edit-scenario/) being executed.
- `x-octoperf`: this header contains the current request path. It contains the virtual user name, the name of each parent element in their order of appearance and name of the request (or its path if name is empty).

In order to configure Instana to properly catch these headers, you might have to load the following in the configuration yaml file of instana at startup:

```yml
com.instana.tracing:
 extra-http-headers:
   - 'x-loadtest-id'
```