The vdimanager provides a web-based interface, the VDI-in-a-Box console, used to configure and manage servers running vdiManager, desktops, templates, images, users, and the grid, all at the grid level. In the VDI-in-a-Box console, the grid appears as one logical server running vdiManager. It is also possible to view the status and activity of each server individually when required, in the console. If the console is unreachable or takes too long to open, then the vdimanager cannot be configured to create desktops on-demand; user requests for desktops can hence not be serviced, resulting in a bad user experience with the entire virtual desktop service! The HTTP test seeks to avoid this unpleasant outcome by periodically checking the availability of the web console and its responsiveness to requests by emulating an HTTP request to the console from an external location.

Target of the test : A VDI-in-a-Box Manager

Agent deploying the test : An external agent; if you are running this test using the external agent on the eG manager box, then make sure that this external agent is able to communicate with the port on which the target Webserver is listening. Alternatively, you can deploy the external agent that will be running this test on a host that can access the port on which the target console is listening.

Outputs of the test : One set of outputs for every URL being monitored.

Configurable parameters for the test
Parameters Description

Test period

This indicates how often should the test be executed.


The host for which this test is to be configured.


The port at which the specified host listens to.


The web page being accessed. While multiple URLs (separated by commas) can be provided, each URL should be of the format URL name:URL value. URL name is a unique name assigned to the URL, and the URL value is the value of the URL. For example, a URL can be specified as HomePage:, where HomePage is the URL name and is the URL value.


Whether any cookies being returned by the web server need to be saved locally and returned with subsequent requests.


The host on which a web proxy server is running (in case a proxy server is to be used).


The port number on which the web proxy server is listening.


The user name of the proxy server.


The password of the proxy server.

Confirm Password

Confirm the password by retyping it here.


Here, specify the maximum duration (in seconds) for which the test will wait for a response from the server. The default Timeout period is 30 seconds.

Measurements made by the test
Measurement Description Measurement Unit Interpretation


This measurement indicates whether the server was able to respond successfully to the query made by the test.


Availability failures could be caused by several factors such as the web server process(es) being down, the web server being misconfigured, a network failure, etc. Temporary unavailability may also occur if the web server is overloaded. Availability is determined based on the response code returned by the server. A response code between 200 to 300 indicates that the server is available. 

Total response time

This measurement indicates the time taken by the server to respond to the requests it receives.


Response time being high denotes a problem. Poor response times may be due to the server being overloaded or misconfigured. If the URL accessed involves the generation of dynamic content by the server, backend problems (e.g., an overload at the application server or a database failure) can also result in an increase in response time.

TCP connection availability

This measure indicates whether the test managed to establish a TCP connection to the server.


Failure to establish a TCP connection may imply that either the web server process is not up, or that the process is not operating correctly. In some cases of extreme overload, the failure to establish a TCP connection may be a transient condition. As the load subsides, the server may start functioning properly again.

TCP connect time

This measure quantifies the time for establishing a TCP connection to the web server host.


Typically, the TCP connection establishment must be very small (of the order of a few milliseconds). Since TCP connection establishment is handled at the OS-level, rather than by the application, an increase in this value signifies a system-level bottleneck on the host that supports the web server.

Server response time

This measure indicates the time period between when the connection was established and when the server sent back a HTTP response header to the client.


While the total response time may depend on several factors, the server response time is typically, a very good indicator of a server bottleneck (e.g., because all the available server threads or processes are in use).

Response code

The response code returned by the server for the simulated request


A value between 200 and 300 indicates a good response. A 4xx value indicates a problem with the requested content (eg., page not found). A 5xx value indicates a server error.

Content length

The size of the content returned by the server


Typically the content length returned by the server for a specific URL should be the same across time. Any change in this metric may indicate the need for further investigation on the server side.

Content validity

This measure validates whether the server was successful in executing the request made to it.


A value of 100% indicates that the content returned by the test is valid. A value of 0% indicates that the content may not be valid. This capability for content validation is especially important for multi-tier web applications. For example, a user may not be able to login to the web site but the server may reply back with a valid HTML page where in the error message, say, "Invalid Login" is reported. In this case, the availability will be 100 % (since we got a valid HTML response). If the test is configured such that the content parameter should exclude the string "Invalid Login," in the above scenario content validity would have a value 0.