12.3. Interact with the demonstration


Active Sessions
A session is considered active if a client thread will ever send a request associated with the session. When client threads stop using a session, they can either send a request to invalidate it, or abandon it by no longer including its session cookie in requests.
Once a session has been abandoned, it is no longer reflected in the Session Balancing chart, but will continue to exist on the worker node until it is removed based on session timeout values.
Total Clients
The number of client threads created since the last time the Start button was clicked.
Live Clients
The number of client threads currently running.
Failed Clients
The number of clients threads that terminated abnormally, for example, a request that resulted in something other than a HTTP 200 response.
This section shows you how to configure and start using the demo.

Task: Interact with the Demonstration

Complete this task to test the effects of changing load-balancing parameters.
  1. Click on the Request Balancing tab to see how many requests are going to each of the worker nodes.
  2. Click on the Session Balancing tab to see how many active sessions are being hosted by each of the worker nodes.
  3. Stop some of the worker nodes, or undeploy load-demo.war, and observe the effect that this has on request and session balancing.
  4. Restart some of the worker nodes, or re-deploy the load-demo.war to some of the workers, and observe the effect that this has on request and session balancing.
  5. Experiment with adding artificial load to one or more worker nodes and observe the effects on load and session balancing. (See Section 12.3.1, “Generate artificial load” for details.)

12.3.1. Generate artificial load

You can use the Load Balancing Demonstration to instruct your worker nodes to generate various types of load, and then track how that load affects request and session balancing. Load generation is controlled in the Server Load Control tab:
Target Hostname, Target Port
The hostname and port number of the server on which to generate load. There are two strategies for setting these values:
  1. Use the hostname and port of the proxy server. The proxy will route the load to a worker node. However, the client does not maintain a session cookie for these requests, so subsequent generated load will not necessarily be routed to the same worker.
  2. If the worker nodes are running the HttpConnector and the AJP connector, you can specify the IP address and port on which a worker's HttpConnector is listening. (The default is 8080.)
Load Creation Action
Specifies the type of load the worker node should generate.

Available Actions

Active Sessions
Generates server load by causing session creation on the target server.
Datasource Use
Generates server load by taking connections from the java:DefaultDS datasource for a set time.
Connection Pool Use
Generates server load by blocking threads in the webserver connections pool for a set time.
Heap Memory Pool Use
Generates server load by filling 50% of free heap memory for a set time.
Generates server CPU load by initiating a tight loop in a thread.
Server Receive Traffic
Generates server traffic receipt load by POSTing a large byte array to the server once per second for a set time.
Server Send Traffic
Generates server traffic send load by making a request once per second, to which the server responds with a large byte array.
Request Count
Generates server load by making numerous requests, increasing the request count on the target server.
Zero or more parameters to pass to the specified load creation servlet, for example, Number of Connections and Duration, as seen in the screenshot. The parameters displayed, their name, and their meaning depend on the selected Load Creation Action. The label for each parameter includes a tooltip that explains its use.