The data you capture will help you identify possible trouble spots in the system. The following are examples of things to look for in the baseline test results.
If identical hardware is used in the test, the number of authentication transactions per second should be roughly the same for each OpenSSO Enterprise instance. If there is a large variance in throughput, investigate why one server behaves differently than another.
Using a load balancer should not cause a decrease in the maximum throughput. In the example above, test 3 should yield results similar to test 1 results, and test 4 should yield results similar to test 2 results. If the maximum throughput numbers go down when a load balancer is added to the system, investigate why the load balancer introduces significant overhead. For example, you could conduct a further test with static pages through the load balancer.
If the throughput numbers do not increase proportionately with the number of OpenSSO Enterprise instances, you have not configured sticky load balancing properly. Users logged in to one OpenSSO Enterprise instance are being redirected to another instance for logout. You must correct the load balancer configuration. For related information, see Configuring Load Balancer 2 for OpenSSO Enterprise in Deployment Example: Single Sign-On, Load Balancing and Failover Using Sun OpenSSO Enterprise 8.0.
For example, if you perform the OpenSSO Enterprise login and logout test, your test results may look similar to this:
# cp access a; grep Login a|wc; grep naming a|wc; grep sesion a|wc; grep policy a|wc; grep jaxrpc a|wc; grep notifi a|wc; grep Logout a|wc;wc a; 1581 15810 139128 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1609 16090 146419 3198 31972 286043 a
This output indicates three important pieces of information. First, the system processed 1581 login requests and 1609 logouts request. They are roughly equal. This is expected as each login is followed by one logout. Secondly, all other types of OpenSSO Enterprise requests were absent. This is expected. Lastly, the total number of requests received, 3198, is roughly the sum of 1581 and 1609. This indicates there are no unexpected requests that we didn't grepin the command.