Load Test Numbers with Different idp.properties settings

[Nate Klingenstein]

The error rate, from what I can tell, is an artifact of concurrency issues in the Grinder script/framework rather than anything in the IdP.  I think the IdP is clean.

7/8/14 5:01:30 PM (thread 1 run 401 test 2): Aborted run due to Jython exception: NameError: wssorq [calling TestRunner]
NameError: wssorq
        File "/opt/grinder-framework/tests/saml2sso_idp/test.py", line 255, in __call__

7/8/14 5:01:30 PM (thread 3 run 397 test 2): Success!
7/8/14 5:01:30 PM (thread 0 run 401 test 2): Success!
7/8/14 5:01:30 PM (thread 1 run 401 test 2): Failure!
7/8/14 5:01:30 PM (thread 1 run 401 test 2): ERROR ("Aborted run due to J..."), see error log for details
7/8/14 5:01:30 PM (thread 2 run 407 test 2): Success!
7/8/14 5:01:30 PM (thread 4 run 405 test 2): Success!

Also, idp.sesson.StorageService was typoed and I pasted that verbatim.  Correcting it to idp.session.StorageService didn't result in any performance change either.

On Jul 8, 2014, at 10:56 AM, "Cantor, Scott" <cantor.2 at osu.edu>
 wrote:

> On 7/8/14, 12:34 PM, "Nate Klingenstein" <ndk at internet2.edu> wrote:
> 
>> I haven't gone back to track down what the errors are yet.  I'll do that
>> next.  The groupings of properties and defaults wasn't obvious to me, so
>> apologies for the useless data.
>> 
>> No obvious performance degradation from:
>> 
>> idp.transientId.generator = shibboleth.StoredTransientIdGenerator
>> idp.sesson.StorageService = shibboleth.StorageService
>> 
>> 107, 95, .06%
> 
> No improvement either, I guess. That rules out the crypto overhead I was
> thinking of. That's useful to know anyway.
> 
> -- Scott
> 
> --
> To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net