SWS Keep Alives Test

Http operates on what is called a request-response paradigm. This means that a client generates a request for information, and passes it to the server, which answers it. In the original implementation of HTTP, each request created a new socket connection to the server, sent the request, then read from that connection to get the response.

While this approach was simple to understand and implement, it was also slow. So, keep-alive connections were invented for HTTP. Under HTTP 1.0, if the browser supports keep-alive, it adds an additional header to the request:

Connection: Keep-Alive

Then, when the server receives this request and generates a response, it also adds a header to the response:

Connection: Keep-Alive

Following this, the connection is NOT dropped, but is instead kept open. When the client sends another request, it uses the same connection. This will continue until either the client or the server decides that the conversation is over, and one of them drops the connection.

Under HTTP 1.1, the official keepalive method is different. All connections are kept alive, unless stated otherwise with the following header:

Connection: close

A web server can receive hundreds of new HTTP requests per second. If every request was allowed to keep the connection open indefinitely, the server could become overloaded with connections. Using the SWSKeepAlive test you can continuously monitor the inflow of keep-alive HTTP connections to the target web server instance, so that you can be proactively alerted to a potential connection overload, and avert it before any irreparable damage occurs.

Target of the test : An Oracle iPlanet Web Server

Agent deploying the test : An internal agent

Outputs of the test : One set of results for the web server instance being monitored.

Configurable parameters for the test
Parameter Description

Test period

How often should the test be executed.


The host for which the test is to be configured.


The port number at which the specified Host listens to.


Specify the name of the administrator of the administration server to which the target web server is registered.


The eG agent connects to the administration server to which the target web server is registered to extract the required metrics. To enable the eG agent to communicate with this administration server, you first need to create a password file containing the administrator password for accessing the server; this password file should be created in the install directory of the web server. Specify the name of this file in the PasswdFile text box; by default, this is admin.passwd.


Specify the IP address of the administration server to which the target web server is registered.


Indicate the port at which the administration server listens.


In Web Server 7.0, all configurable elements of a server instance like web applications, configuration files, and search collection indexes are logically grouped and termed as a Configuration. To enable the test to locate the web server instance to be monitored, you need to mention the Configuration that applies to the instance. In the Config text box therefore, specify the name of the Configuration which the target web server instance uses.


Node is a network resource, such as a server or a host. Instance refers to the environment of a web server daemon on a given node, including its configuration, log files and other runtime artifacts such as lock databases, caches and temporary files. To enable the test to identify the exact web server instance to be monitored, you need to specify the name of the Node on which the instance executes. The test will thus monitor only that web server instance that operates on the given Node and which uses the specified Config.


Set this flag to Yes if the administration server is SSL-enabled; if not, set it to No.


Here, specify the Oracle iPlanet web server installation directory.

Measurements made by the test
Measurement Description Measurement Unit Interpretation

Keep alive hits

Indicates the number of times a request was successfully received from a connection that was kept alive during the last measurement period.



Number of connections added

Indicates the current number of connections in keep-alive mode.


If the Number of connections added measure registers an abnormally high value, or is found to increase consistently, then, it is indicative of a probable connection overload. On UNIX and Linux systems, this could lead to a file table overflow very easily.

To deal with this problem, the server maintains a counter for the maximum number of waiting keep-alive connections. The Maximum connection size measure reports the value of this counter only.

A waiting keep-alive connection is one that has fully completed processing the previous request, and is now waiting for a new request to arrive on the same connection. If the server has more than the maximum waiting connections open when a new connection waits for a keep-alive request, the server closes the oldest connection. This algorithm keeps an upper bound on the number of open waiting keep-alive connections that the server can maintain.

Maximum connection size

Indicates the maximum number of connections allowed in keep-alive mode simultaneously.


No of connections flushed

Indicates the number of times during the last measurement period the server had to close a connection because the total number of connections added exceeded the keep-alive maximum connections setting.


The server does not always close existing connections when the keep-alive count exceeds the maximum connection size. Instead, new keep-alive connections are refused and the number of connections refused count is incremented.

No of connections refused

Indicates the number of times the server could not complete the connection to a keep-alive thread during the last measurement period.


This could happen due to too many persistent connections (or when the total number of connections added exceeds the keep-alive maximum connections setting).

Keep alive timeouts

Indicates the number of times during the last measurement period the server closed idle keep-alive connections because client connections timed out without any activity.



Connection timeout

Indicates the time before idle keep-alive connections are closed.


The default timeout period is 30 seconds, meaning the connection times out if idle for more than 30 seconds. The maximum is 3600 seconds (60 minutes).

Since idle connections are a resource-drain, you may want to fine-tune the timeout settings for your keep-alive connections to prevent the wastage of resources.