jUDDI Load Test Update

[Jeremi Thebeau <ju...@xceptance.com>]

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

Re: jUDDI Load Test Update

[Kurt T Stam <ku...@gmail.com>]

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