Hi Jeremi,
I have not had time to go over it in detail, but thing struck me, which
is that you can use a AuthenticationToken multiple times. You don't have
to get one foreach request, but rather you can cache it in the user's
session.
Great work by the way! I'm working on the website right now, and I hope
to publish all the results in some chronological order :).
Cheers!
--Kurt
Jeremi Thebeau wrote:
Load testing update
A 12 hour long load test was carried out on a jUDDI node last night.
This was done using the SNAPSHOT version of jUUDI
(juddi-portal-bundle-3.0.0.20090723.201427-7) installed on a platform
with the following:
Processor: Intel(R) Core(TM)2 CPU, 6400 @ 2.13GHz;
RAM: 2011 MB;
OS: Ubuntu 9.04, linux kernel 2.6.28-13-generic.
Only one transaction was repeatedly executed during this test:
TFindBusinessByName. The transaction consists of two actions,
GetAuthenticationToken and FindBusinessByName, that enable the users
to search the jUDDI node for a previously published business given a
username, password and business name. GetAuthenticationToken simply
request an AuthToken with the root:root username and password
combination through a SOAP message sent to the server. The token is
then used by FindBusinessByName to submit a second SOAP message
through the inquiry port containing the name of the business to
search. Submitted business names were taken at random from list of
previously published business names containing 8660 entries
(/juddi/config/data/default/BusinessNames.txt). All business names in
the list are unique since they contain a UUID. This ensures that only
one business will be returned in each response. The test was
configured using a constant arrival rate of 100 000 transactions/h, a
maximum of 100 users, a ramp-up period of 2 mins and a 12 hour
measurement period.
Using the constant arrival rate option means that XLT will try to
ensure that transactions are completed at a given rate, here 100 000
transactions/hour, by varying the number of running users. If the
arrival rate is lower than the target rate more users are started up,
if higher, some are stopped. The number of users specified then
becomes the maximum number of users that are allowed to be run to try
to generate this load, here 100 users. The average arrival rate during
the test (88,635 t/h) however never reached the target and the maximum
number of users was used for most of the test. This would suggest that
the measured arrival rate is the maximum load that this specific
system can handle. Shorter subsequent load test would suggest the same.
Attached are the test suite, the XLT generated report of this run and
memory usage and overview screenshots of jconsole running on the server.
Jeremi
