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" |
| [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. |
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.
Related Information
Was this topic helpful?
Document Information
Modified date:
15 June 2018
UID
swg21449249