Benchmark scenarios

To test the different levels of security, we used three categories of test procedures for our Tivoli WebSEAL performance tests.

There were three categories of test procedures we used:

The Tivoli® Access Manager administrative command utility (pdadmin) was used to configure the WebSEAL server for the workloads driven by the benchmarks. The following table describes the WebSEAL configuration, including the pdadmin command options, used for each benchmark scenario.

Table 1. Benchmark scenarios
# Benchmark Description Junction Crypto Auth. type Page Size Back end
1 HTTP page access to a TCP junction to back end TCP None None 5.8 KB WebSphere z/OS®
pdadmin -a sec_master -p <password> server task webseald-<webseal host> create -t tcp -p 9080 -h <websphere server> /ivload/tcp-jct-wasserver-unauth
2 HTTPS page access to TCP junction to back end TCP AES-128 sw/hw Once, with session reuse

5.8 KB
12 KB
2.9 MB

WebSphere z/OS
pdadmin -a sec_master -p <password> server task webseald-<webseal host> create -t tcp -p 9080 -h <websphere server> /ivload/tcp-jct-wasserver
3 HTTPS page access to TCP junction to back end with “-c all” option TCP AES-128 sw/hw Once with session reuse 5.8 KB WebSphere z/OS
pdadmin -a sec_master -p <password> server task webseald-<webseal host> create -t tcp -p 9080 -h <websphere server> -c all /ivload/tcp-jct-wasserver
4 HTTPS page access to SSL junction to back end SSL DES-168 sw/hw Once with session reuse 5.8 KB 12 KB WebSphere Linux®
pdadmin -a sec_master -p <password> server task webseald-<webseal host> create -t ssl -p 9443 -h <websphere server> /ivload/ssl-jct-apache2
5 HTTPS authentication page access None AES-128 sw/hw Each, with new session 100 B None
Note: While it is possible to have an HTTP page access to an SSL junction back end, this configuration was not tested because it is counter intuitive.

Authentication process

Basic authentication requires two requests from the browser. The first request is unauthenticated. It asks for the Web page without providing authentication information, for example, the authentication header. The Web server rejects this request with a HTTP 401 error indicating that authentication is required. The Web browser pops up a user name and password authentication header so that re-authentication does not occur.

SSL sessions

Negotiating a new SSL session is costly in terms of performance (CPU usage). The test that authenticates with each request also negotiates a new session with each request. Although both are very costly, both events occur together, so it is a realistic representation of common usage to perform the test in this way.

"Session reuse" means the SSL session is negotiated at the beginning of the test and the session is reused on each subsequent request.

Authentication types

Authentication type "None" means the request is unauthenticated. For these tests, an Access Control List (ACL) is placed in the WebSEAL object space indicating that the page does not require authentication.

Authentication type "Once" means there is one authentication per load generating client and subsequent requests are performed after this authentication by reusing the same session. The authentication is not part of the measured results. Other than at the beginning of the test, there are no LDAP operations for consecutive tests refers to an authenticated page access request after an initial authentication. Post authentication cases do not perform any operations to the LDAP server.

Authentication type "Each" means that each request creates a new session, which requires a new SSL session negotiation. This includes a user login using Basic Authentication (BA).