Skip to content

HTTP(S) method

General

The HTTP(s) method relates to the hypertext transfer protocol (HTTP) protocol. A single measurement sends an HTTP request to the specified URL using either HEAD or GET as request method and measures the round-trip-time.

When to use the HTTP(S) method

The hypertext transfer protocol (HTTP) is often used to transfer data between a client and a web or cloud service. Also standard browsers use HTPT(S) requests to load websites. Therefore the latency of HTTP(S) requests to such services provides information about experienced performance by the client. This information helps to identify or exclude the network as cause for possible performance issues of that service. A single HTTP(S) request can also be used to just monitor the availability of a service.

Parameters

These are the parameters that are configurable for each test using the ICMP method.

URL

Specifies the address of the target service. The URL has to start with either http or https to determine the protocol to use.

Examples: http://docs.rimscout.com/, https://outlook.office365.com/owa/favicon.ico

Request method

Specifies the request method of the HTTP(S) request.

Allowed selections: HEAD or GET

HTTP status code validation

Specifies the accepted http status codes of the HTTP responses. Responses having a mismatching status code are counted as error. By default only success codes (2xx) are accepted. In case the provided URL returns other known status codes this can be adapted individually.

Allowed custom inputs: Comma-separated numbers or ranges (that are denoted with a - between start and end of the range) between 100 and 1000.

Examples: 200, 200-299,307

Number of measurements

Specifies the number of HTTP(S) requests send per minute. To measure the performance a value between 5 and 10 measurements is recommended. It is also recommended to have not more than 20 requests to not overload the client or service. To measure the availability one or two requests are sufficient.

Allowed input: 1 - 58

Example: 10

Warning/critical threshold

The thresholds define the latency beyond which a measurement gets the status warning or critical. A usual HTTP request to a (nearby) service typically takes between 50 - 400ms. If an HTTP request takes more than 800ms users usually start to notice some delay.

Base warning threshold: 400ms
Base critical threshold: 800ms Allowed inputs: 1 - 10.000 and has to be less than the critical threshold.

Status percentage

See Status percentage. Around two slow HTTP(S) requests per test run are normal and generally not noticeable for the experienced performance.

Allowed input: 1 - 100.

Limitations and recommondation

  • If possible use rather HEAD than GET requests for performance measurement. Although the services are accessed using GET requests, HEAD request work similar enoug to measure the response time while using less network bandwidth for the response.
  • To produce less load on the responding server it is recommended to request static files (e.g. a favicon).
  • Most operating systems limit the number of concurrent TCP connections in pending which can impact the client. Therefore do not execute too many TCP-based tests (HTTP(S) is TCP-based) on one client. It is recommended to have not more than 10 TCP-based tests.
  • Note that an HTTP(S) test respects the proxy settings of a client.

Example test

There are two managed tests that are using HTTPS to monitor the performance to cloud services: The Outlook client test and the Teams client test. Both are measuring the performance to the Teams and Outlook cloud services by sending HEAD requests to the corresponding URLs.