Working with the HTTP sensor

Understanding the HTTP Timer

The HTTP timer view thus provides you with interesting starting points for monitoring and diagnosis if you dealing with a webbased application. Instead of methods of classes you can see the aggregated timings and calling frequency of the webpages of your application.

The HTTP sensor extends the functionality of the Timer sensor with HTTP based information. Where Timers measure method execution times, the HTTP Timer measures the execution time of a webbased request. It is important to understand that the HTTP sensor will only provide one measurement per request. That means that even if you attached the HTTP sensor to multiple methods within the execution of a request only the first invocation (that provides Http information) is measured. This is done to allow for easier analysis in the aggregation views. Think of the aggregation based on the requested URI. You might want to count the number of requests that the user had to a given URL, but this is only possible if we ensure that only one metric is captured for each request, right?

URI Aggregation

The URI based aggregation shows all current HTTP Timers that are available in the buffer (see Working with the in-memory storage) aggregated by the URI of the request. Note that you see only one metric is recorded per request, so the provided count is the number of distinct requests.

Just like a common Timer, the HTTP Timer in this aggregated view can easily be navigated to get a detailed view of all invocation sequences that contain requests to this URI. You can use this functionality to easily analyze these requests. It is also a great functionality for analyzing the one request that took significally longer than the rest.

Use case Aggregation

HTTP Timers can also be aggregated on different information than their URI. With the Use Case Aggregation the HTTP Timer Data is aggregated based on the value of a given HTTP Header. If you are using a load testing tool you might want to integrate this specific header (called "inspectit") and add a meaningful value that describes the current step in your use case in more detail. 

In the inspectIT DVD Store sample application we could integrate the "inspectit" header to get a more detailed overview of what use case we are currently executing. So in fact the screenshot you see below is based on the same data as in the URI Aggregation. It is just a matter of perspective :)

Loading data from a specific time-range

HTTP views enables a user to specify a time-range that the displayed data should be in. By clicking to the icon the time-range selection opens, where you can select the wanted time-range for displayed data. Note that the entered duration will be relative to the selected until date. Selecting duration of one hour to the current time, will display the data that was collected in the last hour.

Detailed analysis in invocation sequences

All HTTP Timer are also automatically integrated in invocation sequences. Here the HTTP Timer will provide detailed information about the HTTP parameter, attributes, headers, ... that this request sent to your application. Notice that the URI of the request is provided in the parameter column of the invocation sequence. If you right-click an element and select "Details" you will see more information about the element. If this element provided a URI, then you will see additional HTTP information.

Limitation: No long time storage (yet)

Http data is currently not saved for long time monitoring as Timer data is (see Viewing historical data). That means that all data that is currently displayed is served by the in-memory buffer (Working with the in-memory storage). If the buffer needs to drop data due to a high amount of data within the buffer, older http timer data will be removed. 

https://jira.novatec-gmbh.de/browse/INSPECTIT-439