Highlighted
Absent Member.
Absent Member.
197 views

WebSphere Portal Performance Measurement

We are conducting performance measurement exercises for IBM WebSphere Portal v6.1.0.1. In order to drive the portal to saturation point in a load test, we need to ramp up users sufficiently to simulate a real world scenario.

The issue is regarding user IDs (created on LDAP/AD) versus the number of virtual users. We can create any number of virtual users by logging in actual users multiple times – we only have 20 test user IDs.

This doesn't work for Portal. User data is not updated in the DB as Portal detects the simultaneous login and does nothing. So what you are left with is an artificial performance bottleneck/unrealistically high CPU load and/or lock contention on the DB server.

The message logged is:

com.ibm.wps.engine.commands.LoginUser execute EJPSD0027E: User data for user Yin_006_992 was not updated due to multiple logins.

In an IBM document entitled "IBM WebSphere Portal Performance Troubleshooting Guide" (December 2008) it states that you should "…create a pool of user IDs to be used in the load test. This pool of user IDs should be at least 25 times as large as the maximum number of virtual users being used."

This is unrealistic in our current environment. Even if we wanted to test 1,500 users, which is the target amount for go-live, it wouldn't really be allowed from a risk and compliance point of view.

What, if any, is the recommended process to simulate actual users for a load test without having to create 1,500 test users on AD?

Your insight would be greatly appreciated.
0 Likes
2 Replies
Highlighted
Absent Member.. Absent Member..
Absent Member..

Re: WebSphere Portal Performance Measurement

I don't think you have much of a choice in this instance. Most companies can accomodate a large volume of test users in LDAP/AD, so it will be up to you to push the case for creating them. I typically create a minimum of 1,000 users for any client-facing application of reasonable size.

The limiting factor here is that your target is the Portal. There is little flexibility in using LoadRunner to create an artifical load for this layer - it is 1:1 between vuser and user. However, I would suggest that the Portal is not really a high-risk area, at least not in relation to the AS. Your ROI is probably more in running high loads (min think times) with your 20 users, and then tuning the JVM.
0 Likes
Highlighted
Absent Member.
Absent Member.

Re: WebSphere Portal Performance Measurement

Thanks for the info and the tip about small think times. All evidence points to your answer.
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.