Hyper Text Transfer Protocol (HTTP) traffic dominates Internet traffic. The exchange of HTTP messages is implemented using the connection-oriented TCP. A TCP connection which is kept open and reused for the next HTTP request reduces overhead and latency. Open connections consume sockets and memory for socket-buffers. This is where Persistent Connection Manager (PCM) comes into play. Prior to persistent connections, a separate TCP connection was established to fetch each URL, increasing the load on HTTP servers and causing congestion on the Internet.
Persistent HTTP connections have a number of advantages:
- By opening and closing fewer TCP connections, CPU time is saved in routers and hosts (clients, servers, proxies, gateways, tunnels, or caches), and memory used for TCP protocol control blocks can be saved in hosts.
- HTTP requests and responses can be pipelined on a connection. Pipelining allows a client to make multiple requests without waiting for each response, allowing a single TCP connection to be used much more efficiently, with much lower elapsed time.
- Network congestion is reduced by reducing the number of packets caused by TCP opens, and by allowing TCP sufficient time to determine the congestion state of the network.
- Latency on subsequent requests is reduced since there is no time spent in TCP’s connection opening handshake.
- HTTP can evolve more gracefully, since errors can be reported without the penalty of closing the TCP connection. Clients using future versions of HTTP might optimistically try a new feature, but if communicating with an older server, retry with old semantics after an error is reported.
Persistent connection management is performed at the HTTP-application layer. Current implementations of Web servers use a holding-time model rather than a caching model. Using holding-times, a server sets a holding time for a connection when it is established or when a request arrives. While the holding-time lasts, the connection is available for transporting and servicing incoming HTTP requests. The server resets the holding-time when a new request arrives and closes the connections when the holding-time expires. In a caching model there is a fixed limit on the number of simultaneously-open connections.
HTTP persistent connection is also known as HTTP keep-alive or HTTP connection reuse. Businessworks provides PCM via engine properties as listed below:
- bw.plugin.http.client.usePersistentConnectionManager: This property specifies that a pool of HTTP connections need to be created which may be re-used by Send HTTP Request activities. By default this is set to false. When set to true, a pool of connections is created for each HTTP Server that Send HTTP Request activity connects to.
- bw.plugin.http.client.connectionTimeout: This property specifies the time frame (in milliseconds) for which the HTTP Connection should stay alive for each HTTP server. The default value is 3000 ms.
- bw.plugin.http.client.maxConnectionsPerHost: The total number of connections for each HTTP Server is specified using this property. The default value is 20.
- bw.plugin.http.client.maxTotalConnections: The total number of connections is pool is set using this property. The default value is 200.
- bw.plugin.http.client.checkForStaleConnections: This property is used to specify whether a connection should be checked if it has become stale before re-using it. HTTP specification permits both the client and the server to terminate a persistent (keep-alive) connection at any time without notice to the counterpart, thus rendering the connection invalid or stale. One should note that checking for stale connections adds processing overhead. The default value is false.
Persistent connections cannot be used for HTTPS connections with Businessworks. When using PCM, a HTTP header “Connection: Keep-Alive” is added to specify that the connection needs to be kept open. When server is done processing request, it also adds a HTTP header “Connection: Keep-Alive” to the response message. When the client sends next request, it uses the same connection. This continues until either the client or the server decides that the conversation is over, and one of them drops the connection.