Bug 6102 - GRAM4 throughput tester for 4.2
: GRAM4 throughput tester for 4.2
Status: RESOLVED FIXED
: GRAM
Campaign
: development
: Macintosh All
: P3 normal
: 4.2.1
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2008-05-23 17:11 by
Modified: 2008-09-30 17:16 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2008-05-23 17:11:22
For 4.2, we want to improve the GRAM throughput tester so that clients/users
can use section in the code in their client implementations.  This will involve
documenting the code well and adding a link/transition from the user's guide to
the throughput tester code.  Additionally, the throughput tester will be use to
isolate performance at greater detail than the 4.0 throughput tester.  In
particular, separate tests will be possible to reuse client stubs in order to
take advantage of JavaWS Core's http connection caching.  This feature could be
valuable to gram user's, but it's value it not yet known.  The throughput
tester's results will show a measurable value for clients to then make
implementation decisions.

Deliverables:

1) throughput tester implementation
2) throughput tester 4.2.0 performance results
3) 4.2 user documentation linking/transitioning to throughput tester code
------- Comment #1 From 2008-06-18 17:26:42 -------
Status:

The tester can be used functionality-wise. The code is sitting in a branch.
More comments need to be added to make it usable in our docs; the logging
needs to be reviewed maybe. Some security-related issues should be reviewed
by Rachana at some point.

Currently it can be run as a command-line program, but it's planned to also
run it with Toms Test-Controller framework that is currently in work, to be
able to run several tests in a row in an automated way, with clients on 
different machines and the server being synchronized by the Test-Controller 
framework.
Running it with Toms framework means adding a dependency to code that is
not yet ready, and it's not yet clear where that code will find it's place
in CVS. Currently it's in the playground.
I guess that's fine though, since that tool will help us in automating
and controlling a series of tests.

The functional configuration parameters of a test and their meaning are as
follows:

# Job factory used for submission. The delegation endpoints are found by
# checking the appropriate RP's of the factory service.
jobFactoryAddress=https://osg-test1.unl.edu:8443/.../ManagedJobFactoryService

# Local resource manager used in submission. If no one is specified then
# the default local resource manager defined on the server-side will be used.
localResourceManager=Fork

# Job description that is used for all jobs in submission
jobDescriptionFile=job_si_so_fcu.xml

# Duration of the test, unit is in seconds. A value < 1 means that
# the test will not be stopped due to time limits.
testDurationSeconds=0

# The number of jobs to be submitted. If the specified number of jobs has
# been submitted and finished, the test will terminate. A value < 1 means
# that there's no job limit.
totalNumberOfJobs=1000

# Number of threads used for server-interaction in job submission, resource
# property queries, job termination. A value < 1 is not allowed.
concurrency=50

# Max number of jobs in the server at a time submitted by this client.
# A value < 1 means that there is no limit, i.e. all threads keep on
# submitting all the time until either all jobs have been submitted or
# the testDuration elapsed.
maxLoad=0

# Periodical polling for job status after the specified number of seconds.
# A value < 1 means that there is no polling.
jobStatusPollingIntervalSeconds=0

# Defines whether a job credential should be delegated or not.
delegateJobCredential=false

# Defines whether delegation (job or staging) should be done per job or
# one credential should be shared amongst all jobs.
delegatePerJob=false

# Subscribe for state-change notifications of gram jobs or not
subscribeForJobStatus=true

# If set to true GramJob will be used for all actions, otherwise stubs will
# be used.
useGramJob=false

# If set to true and GramJob is not being used cached stubs will be used
# where possible. By this http connection caching in job submission can be
# leveraged.
reuseStubs=true

# Timeout in seconds after which unused stubs won't be reused anymore
# A value > 0 must be specified if reuseStubs is set to true, recommended
# is a value lower than 120. If reuseStubs is set to false, this value must
# be < 1 
stubIdleTimeoutSeconds=60
------- Comment #2 From 2008-09-29 09:33:37 -------
Added and changed test parameters:

maxErrors: stop test after N errors occurred
terminateOnExpiration: let outstanding jobs finish, or terminate jobs
concurreny: renamed to maxPendingRequests (same parameter in condor-g)
load: renamed to maxSubmittedJobsPerResource (same parameter in condor-g)
pathToClientSecurityDescriptor: xml client security descriptor
pathToNotificationConsumerSecurityDescriptor: xml notif consumer sec desc

database persistency of a test-run is available, turned off by default.

committed to 4.2 branch and trunk. will be in 4.2.1.