CAS: Performance notes

Summary of performance tests

Each of the first three tests were done once with 200 clients talking to the server serially and then with all them talking to the server concurrently. Each number is an average of the time taken to get a locator and handle to the CASPort and the actual method invocation. All numbers are in milliseconds.

The stress test framework in GT3 Core was used for testing. This framework allows a block of code defined in an "init" method for initializing, code to be timed in "run" method and finally a "postRun" methd. Two of the numbers the stress framework that are of relevance here are

The server and client were run on the same machine. Database (PostGres) was used and was also on the same machine.

Platform

All tests were run on a i686, 2.2GHz machine running Linux 2.4.18.

Database status

All tests were run with two different sets of data in the backend database. But in both cases the default bootstrap was done which populated the database with service/action implict to CAS service.

In the case of smaller data set, other than the data described above, a single trust anchor, usergroup, user and object was added. Two policies were added - one granting that user group super user permissions on the CAS server and another granting it access to the external object added. (only the latter is returned on an assertion generation request.)

In the other case, 100 user groups, 100 users, 100 resources and 1000 polices was added above the deafult data. Each user group was given ten polices across the resources.

Test results

Running performance tests

All the classes needed to run these tests are in the package org.globus.ogsa.impl.base.cas.server.test.performance and targets have been provided in the build file for running them.
Setting up database

These targets add some specific number of users to the database. One of the users needs to have the subect DN of the credential that will be used while running the tests. This is picked up from a variable "subject1DN" from a file, whose name is passes as a system property to each of this target. But default, this is set to "casTestProperties". To override it, set -Dcas.test.properties while invoking the target.

To get configuration parameters for database access, a file with database information is required as shown here. This is by default, "casDBProperties". To override it, set -Dcas.db.properties while invoking the target.

To set up small datasets in database, the following from CAS_HOME

  psql -U tester -d casDatabase -f etc/delete.sql
ant bootstrap
ant populateDB -Dargs="small"

To set up large datasets, but credential size less than 50K, in database, the following from CAS_HOME

  psql -U tester -d casDatabase -f etc/delete.sql
ant bootstrap
ant populateDB -Dargs="large"

To set up large datasets, but credential size greater than 50K, in database, the following from CAS_HOME

  psql -U tester -d casDatabase -f etc/delete.sql
ant bootstrap
ant populateDB -Dargs="large largeCred"
Setting up GT3 container
For large runs (greater than 200 clients) and/or large credential generation(greater than 50K), the default timout on the Stub needs to be altered. This can be done by editing the GLOBUS_LOCATION/build.xml, stress target and adding the following as another system property. The value needs to be set appropriately.
	<sysproperty key="org.globus.ogsa.client.timeout" value="200000"/>

The above is the solution if "Read timeout error" is seen on the client side. In all other cases, a default GT3 container with CAS service deployed should suffice.

Running test targets
All tests use the stress framework in GT3 core. For more details, refer to test documentation in GT3 distribution. All targets have the following options: In each case the output is dumped as XML file in the directory from which the test is run.
Infrasture overhead test

The whoami method on CAS port was overridden to just return a dummy string without any processing. The above described "Basic Query Test" was done to measure performance with 200 serial and concurrent client. On serial testing, time taken was 252ms (252) and on concurrent testing it was 187ms (34209). So it appears that irrespective of the application code, the infrastructure takes a considerably long time on concurrent calls.



Updated: 08 - 04 - 2003