wiki:SrmTestSuite
Last modified 11 years ago Last modified on 08/20/07 19:48:52

Setting up the SRM Testsuite

This page is about to setup the S2 tests.

The tests are frequently run by Flavia Donno against all SRM 2.2 endpoints known to her. Results are available here?.

Installing the testsuite

Preparations as ROOT user

  • Get and install the latest RPM from the S2 homepage
  • make sure you have globus-url-copy in your $PATH (it comes with the vdt_globus_essentials RPM)

as normal user

  • make a copy of the subdirectory /opt/s2/share/doc/s2-<version_nr>/testing to a place, where you can write to (that target directory is from now on referred to as $s2_user_dir)
  • add /opt/s2/bin to your $PATH
  • get a valid voms-proxy and put it in /tmp/x509up_u<your_user_id> with permission mask 600
  • select a specific endpoint (otherwise tests against ALL known endpoints are run). A list can be found in /opt/s2/share/doc/s2-0.2.8/testing/scripts/protos/srm/s2.env

Example for DESY endpoint:

export S2_TEST_SITE=22DCACHEDESY

Performing tests

Change to $s2_user_dir/testing/scripts/protos/srm/2.2. There are several directories corresponding to test catiegories:

  • avail - very simple tests (like ping) to test whether a endpoint is up
  • basic - simple SRM calls, which build the building blocks for more complex transactions
  • usecase - sequences of SRM calls to simulate real-life usage (like putFile)
  • stress - performance tests

Tests are performed by running make test. Depending on your current working directory, a number of tests get executed. If you are in $s2_user_dir/testing/scripts/protos/srm/2.2, all tests are run (can take a long time). By changing into a subdir, you select only the tests in that particular directory.

You can also run a single tests by simply executing the wrapper script.

Configuring the stress tests

In the stress-subdir, you will find a s2_local.env-file which allows you to steer the stress tests. They entries mean:

  • N_THREADS - number of parallel requests to be sent to the server
  • SLEEP_SOR - The number of seconds of delay between two status polls
  • LOOP - how many times a test is executed (not honored by all stress tests)

You also have to enter the tag of your endpoint you want to test against. Example for DESY:

#!/bin/bash
# Check for dCache
if test "x${S2_TEST_SITE}" == "x22DCACHEDESY"; then
# Number of Threads
Export N_THREADS 20
# Polling frequency
Export SLEEP_SOR 5                   # sec (Status of Request)
# Looping
Export LOOP 5
fi