IBM Support

IBM web server plug-in is not load balancing evenly

Troubleshooting


Problem

IBM web server plug-in appears to not be load balancing correctly. Too much load is going to only one of the members (application servers) in the cluster. Why is this happening?

Symptom

During load testing, you might notice that a lot more work is being handled by only one application server in the cluster. However, the other application servers in the same cluster are much less busy by comparison.

Cause

The IBM web server plug-in only load balances non-affinity requests. These are new requests that do not have a session cookie (JSESSIONID) in the request.

On the other hand, if it is an affinity request, that does have a session cookie (JSESSIONID), then the plug-in will honor session affinity by sending the request to the same application server as before. It will use the application server which matches the cloneid in the JSESSIONID cookie.

Diagnosing The Problem

To diagnose the problem, you can enable "Stats" logging in the web server plug-in configuration file (plugin-cfg.xml) by setting the following log level:

LogLevel="Stats"

The STATS entries in the plug-in log file (http_plugin.log) will show the number of total requests and affinity requests for each application server. The entries will look like the following:

[Wed Oct  6 13:51:03 2010] 000015f9 f122cba0 - STATS: ws_server: serverSetFailoverStatus: Server Node01_member1 : pendingRequests 0 failedRequests 0 affinityRequests 400 totalRequests 412.

[Wed Oct  6 13:51:04 2010] 000015f9 f302fba0 - STATS: ws_server: serverSetFailoverStatus: Server Node02_member2 : pendingRequests 0 failedRequests 0 affinityRequests 877 totalRequests 889.

First you need to make sure you are looking at STATS information from the same plug-in process ID (000015f9). If there are multiple different process IDs, you will need to pull out (grep) only the requests for the same process id. You may want to consider configuring your web server to use only a single child process instead.

When you look at the first log entry above, you can see that the plug-in has sent 412 total requests to Node01_member1. Of that, 400 were affinity requests. So, to determine the number of new requests, we need to subtract the affinity requests from the total: 412 - 400 = 12 new requests

Likewise, by looking at the second log entry above, you can see that the plug-in has sent 889 total requests to Node02_member2. Of that, 877 were affinity requests. So, to determine the number of new requests, you subtract the affinity requests from the total: 899 - 877 = 12 new requests

As you can see, the second application server (member2) will be doing a lot more "work" because there have been a lot more affinity requests sent to it. However, the load balancing of new requests is perfectly equal (12 new requests sent to each application server).

Those two entries from the plug-in log show us that the plug-in is working correctly. It is load balancing new (non-affinity) requests equally between the cluster members. It is also honoring session affinity by sending the affinity requests to the same application servers as before.

Resolving The Problem

This is a common problem when doing load testing if the testing software does not accurately emulate different browser processes. For example, if you open a web browser and login to the application. Then you open another window or tab from the same browser and login to the application again. Both of those requests will be sent to the same application server, because they are both using the same browser process, and the same JSESSIONID cookie. So, the plug-in honors session affinity by sending the second login request to the same application server as the first login request.

To avoid the effects of session affinity, you must use different browser processes. So, you can open a browser and login to the application. Then you must completely close that browser. Then open a new browser from the icon. Then login to the application again using the new browser. Since this is a new browser process, it will not have the JSESSIONID cookie. So, the plug-in will load balance this request.

If using load testing software, you will need to configure it so that it uses different browser processes, not just different threads of the same browser process. Every initial request (like a fresh login to the application) must not have the JSESSIONID cookie, so that these new requests will get load balanced. After that, every subsequent request (page2, page3, page4, and so on) will, and should, have the JSESSIONID cookie so that session affinity is preserved for those requests.

In production, your users will be connecting from different browsers on different systems. The first request from each user will be load balanced by the Plug-in. The second and subsequent requests from the same user will be affinity requests and will be routed by the plug-in back to the same application server as before.

Note: Plug-in load balancing and session affinity can be broken when there are failed requests. Notice the Stats entries above show 0 failed requests. If your plug-in log shows a nonzero number of failed requests, you must troubleshoot and resolve the failures FIRST. Then you can come back and look at the session affinity and load balancing after the failures have been fixed.

[{"Product":{"code":"SSEQTP","label":"WebSphere Application Server"},"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Component":"Plug-in","Platform":[{"code":"PF002","label":"AIX"},{"code":"PF010","label":"HP-UX"},{"code":"PF016","label":"Linux"},{"code":"PF027","label":"Solaris"},{"code":"PF033","label":"Windows"}],"Version":"9.0.0.0;8.5.5;8.5;8.0;7.0","Edition":"","Line of Business":{"code":"LOB15","label":"Integration"}}]

Document Information

Modified date:
15 June 2018

UID

swg21449249