time taken for code

[lowbk]

hi guys, i'm using tomcat321 and need some help with the following situation

i've a jsp that activates a servlet and the result is put to jsp

JSP1 (on submit) => servlet1 => JSP2

within the servlet, i want to see the time taken for a particular code, so i used

java.util.Date start = new java.util.Date();
//...code to test
java.util.Date end = new java.util.Date();

timetaken = end.getTime() - start.getTime();
System.out.println(timetaken);

with that, i can see the time taken in the tomcat window.
if i click back in JSP2 to JSP1, then activate JSP1 again, the time taken is different. the time taken can be as high as 268, or as low as 62, given the same input (since i just click 'back' on JSP2 and 'submit' on JSP1)

why the difference? any kind soul pls advise

 

[meadandale]

What is your code doing? Is it accessing a database? Making calls over the network? Generally, if your code is localized, the runtime should be fairly consistent from time to time. If, however, you are making database access or doing other work over the network, you will find that the runtime varies quite a bit. This is mostly do to network latency and availability of the server you are talking to. What's the code look like in your servlet?

 

[lowbk]

the code in the servlet does the following
1. takes in a keyword from jsp1
2. load index file
3. read the file to a data structure
4. access the data structure based on keyword
5. issues SQL statements to database
6. process the resultset and put to a vector
7. return the vector

 

[meadandale]

That's what I thought. Although you may find SOME variability in the file reading, the real killer is your database access. It is the cause of your differences in runtimes.

I had to do some performance analysis of a transaction processing system we had developed in java at one point. I found that to process a number of transactions, say 1000, that the runtime could vary between by large amounts. One run would take 3 minutes, the next would take 5. This was due to the large number of database access that were required (several queries and then at least one update for each transaction).

Regards,

Charles