You can fine-tune your client/server system
with server load-balancing and client thread use of pool connections. For example, you can
configure how often the servers check their load with the cache server
load-poll-interval property, or configure your own server load metrics
by implementing the com.gemstone.gemfire.cache.server package.
How Server Load Conditioning Works
When the client pool requests connection information from the server locator, the locator
returns the least-loaded server for the connection type. The pool uses this "best
server" response to open new connections and to condition (rebalance) its existing
- The locator tracks server
availability and load according to information that the servers provide.
Each server probes its load metrics periodically and, when it detects a
change, sends new information to the locator. This information consists of
current load levels and estimates of how much load would be added for each
additional connection. The locator compares the load information from its
servers to determine which servers can best handle more connections.
- You can configure how often the
servers check their load with the cache server’s
load-poll-interval. You might want to set it lower if
you find your server loads fluctuating too much during normal operation. The
lower you set it, however, the more overhead your load balancing will use.
- Between updates from the servers,
the locators estimate which server is the least loaded by using the server
estimates for the cost of additional connections. For example, if the
current pool connection load for a server’s connections is 0.4 and each
additional connection would add 0.1 to its load, the locator can estimate
that adding two new pool connections will take the server’s pool connection
load to 0.6.
- Locators do not share connection
information among themselves. These estimates provide rough guidance to the
individual locators for the periods between updates from the servers.
GemFire provides a default utility that probes the server and its resource
usage to give load information to the locators. The default probe returns the
following load metrics:
- The pool connection load is the
number of connections to the server divided by the server’s
max-connections setting. This means that servers with a
lower max-connections setting receives fewer connections
than servers with a higher setting. The load is a number between 0 and 1,
where 0 means there are no connections, and 1 means the server is at
max-connections. The load estimate for each additional
pool connection is 1/max-connections.
- The subscription connection load is
the number of subscription queues hosted by this server. The load estimate
for each additional subscription connection is 1.
To use your own server load metrics instead of the default, implement the
ServerLoadProbe or ServerLoadProbeAdapter and
related interfaces and classes in the
com.gemstone.gemfire.cache.server package. The load for each
server is weighed relative to the loads reported by other servers in the system.
Client Thread Use of Pool Connections
By default, a client thread retrieves a connection from the open connection pool for
each forwarded operation and returns the connection to the pool as soon as the
request is complete. If your client thread runs a put on a client
region, for example, that operation grabs a server connection, sends the
put to the server, and then returns the connection to the pool.
This action keeps the connections available to the most threads possible.
Set Up a Thread-Local (Dedicated) Connection
You configure threads to use dedicated connections by setting
thread-local-connections to true. In this case the thread holds
its connection either until the thread explicitly releases the connection, or the
connection expires based on idle-timeout or
Release a Thread-Local Connection
If you use thread-local connections, you should release the connection as soon as
your thread finishes its server activities.