Use a connection pool between Java Agent and AM to reuse connections, and so reduce the overhead of creating new connections.
Connection pooling can improve performance in some circumstances. Test and tune the performance of your deployment with connection pooling before you use it in a production environment.
The following image shows the architecture of a connection pool:
When a client makes a request, the agent intercepts the request, and uses the connection pool to connect to AM. If a connection is available, the agent uses that connection. The client is unaware of the connection reuse.
If a connection is not available, and the maximum number of connections is not reached, the agent creates and uses a new connection. When the maximum number of allowed connections is reached, the request waits until an existing connection is released, or a new connection can be created.
When the request is complete, the agent closes the connection to the pool but the physical connection is retained by the pool. The connection is then available to requests with the same connection parameters.
The following image shows the flow of information when a request is treated in a connection pool:
When Enable Connection Pooling
true, use the following properties to tune the connection pool:
By default, the connection pool can contain up to 1000 HTTP connections. Change the value of this property according to the AM load, as follows:
By default, connections wait for up to 10 seconds for a response before they are considered stale.
Tune this property to allow enough time for systems to respond, and therefore prevent unnecessary failures, but to minimize the time to wait after a network failure.
By default, when a continuous data flow between the connection pool and AM is interrupted, the socket is considered stale.
Tune this property to allow enough time for systems to respond, and therefore prevent unnecessary failures, but to minimize the time to wait after a socket failure.
By default, after a request is complete the connection is returned to the connection pool. The physical connection is retained and can be reused by another request with the same connection parameters.
Reuse connections to reduce the overhead of creating a new connection each time one is requested.
If you are using the connection pool only as a throttling mechanism, to limit the total number of simultaneous connections, it is not necessary to reuse connections.
When Enable HTTP Connection Reuse
By default, requests are retried up to three times after failure.
If requests are likely to pass on retry, enable this property to reduce the overhead of unnecessarily killing and remaking connections.
If requests are likely to fail on retry, disable this property to reduce the retry time.