This however includes the WSS4J and XML-Security startup times. Try "warming them up" first.

for( int i = 0; i < 5; i++ ) {
    WSS4JHandler.processMessage(smc, true);
}

Followed by your current code.

If you are running one-off requests from a client (i.e. the client starts, makes a request, then ends - JVM exits) then your timings are a valid representation of your requirement. If, on the other hand, you will run a JVM then make lots of requests then you should account for that by allowing the various components to initialize before doing any timing tests. You should also allow the JVM time for the JIT compiler to optimize the code. Consider on the server that it will run for a very long time handling thousands of requests (so the 5 in the loop above could be increased to possibly get a still better time).

Pete

Fang Jian wrote:
No, it does not include the JVM startup time. The time
measurement is as follows,

        long runTime = System.currentTimeMillis();
        try{
            WSS4JHandler.processMessage(smc, true);
        } catch (WSSecurityException ex){
            System.out.println(ex.getStackTrace());
        }
        runTime = System.currentTimeMillis() -
runTime;

Thanks,

Jian

--- Dustin Breese <[EMAIL PROTECTED]> wrote:

  
Hi, Fang, no problem.  I'm so burried under all the
info right now and
trying to figure things out myself.  One more
question -- does your
timing represent anything such as the JVM startup
time, etc?  That
could cause a huge difference, of course.

Take care,
Dustin
    



		
__________________________________ 
Yahoo! Music Unlimited 
Access over 1 million songs. Try it free.
http://music.yahoo.com/unlimited/

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

  
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to