All Things WebSphere

If your WebSphere Application Server deployment is experiencing an imbalance in HTTP traffic routing from the WebSphere Plugin please take the following configuration and recommendations into consideration

1. RANDOM load balancing is better than ROUND_ROBIN for load balancing. With RANDOM for all non-affinity requests, the server is “picked” randomly.The affinity requests are sent to the matching clone id. LoadBalance “weight” is not used at all in the Random case.
2.  An affinity request is one where session affinity is established by the first request. All subsequent requests with the same sesssion ID are termed as "affinity requests". Plugin ALWAYS obeys session affinity when routing requests and routes to the appserver targeted on the first request that established affnity.
3. In Round Robin load balancing, the first request is routed randomly. After that, the plug-in will use the next server in the list and so on… (member1, member2, member3, member4). Each time a server is “picked”, the load balance weight is decremented by one. Any server with a weight below 0 will NO longer be used for new requests. But, affinity requests will still go through.When all servers have a weight of less than 0, the plug-in will “reset” the weights to the starting values. By default affinity requests do NOT cause the plugin to decrement the weight of the server. This can lead to an uneven distribution when there are many affinity requests.
• One options you have is to set the property IgnoreAffinityRequests="false". If IgnoreAffinityRequests="false" then the weight IS lowered by each affinity request, leading to a more balanced routing in a Round Robin environment. This can have some adverse consequences if you get a burst of non-affinity requests, they could all be targeted to the servers with the lowest weight and can cause issues with that server. To protect against this, you can defined the maxconnection setting in conjunction, which would avoid having too many non-affinity requests sent to a single server at any one time.

If you already have plugin traces or are willing to enable debug to triage this issue further WAS IBM HTTP Server guru and WebSphere plugin expert Eric Covener has the following scripts that will help analyze your plugin trace and provide a summary of your plugin HTTP routing statistics https://github.com/covener/plugin-tools

For recommended values of the plugin configuration please look at  http://www-01.ibm.com/support/docview.wss?uid=swg21318463
To understand HTTP Plugin load balancing  see http://www-01.ibm.com/support/docview.wss?uid=swg21219567
Demystifying the WebSphere Plugin http://www-01.ibm.com/support/docview.wss?uid=swg27014498&aid=1

How do you determine if this is an "affinity" request
 ) Check for SSLJSESSION cookie
2) Check for JSESSIONID cookie
3) Check for URL rewrite (jsessionid) in the URL
4) Check partitionID against partition table if any

How do you know which server was picked by the WebSphere Plugin ?
The trace shows which server was “picked”. Search the trace file (http_plugin.log) for the string “picked, weight” to quickly see which servers are being chosen in what order.
[Wed Sep 10 17:26:29 2008] 00001f18 00000cb0 - TRACE: ws_server_group:
lockedServerGroupUseServer: Server GAME3Node01_member4 picked, weight 6.
[Wed Sep 10 17:26:29 2008] 00001f18 00000cb0 - TRACE: ws_server_group:
serverGroupIncrementConnectionCount: Server GAME3Node01_member4 picked,
pendingConnectionCount 1 totalConnectionsCount 1.
[Wed Sep 10 17:26:29 2008] 00001f18 00000cb0 - DEBUG: ws_server_group:
serverGroupNextRoundRobinServer: use server GAME3Node01_member4

Labels: WebSphere Plugin