hello, i just profiled my reporting application when i tried to generate four times the same report in a row. the first one took 1859ms whereas the following ones only took between 400 and 600ms. what is the explanation for that? could i somehow use it to make my application faster? the reporting module runs on the server and waits for the user to click on "print report"..
+2
A:
Subsequent runs of the report have expanded memory and filled various caches.
Never having seen your app, my guess would be the biggest effect is that your database server caches the data you query for. It loads the data off disk and into memory, and having nothing better to do with that memory, it leaves it there. Next time the query comes along, the database doesn't have to go to disk for the data, it's still there in memory.
The obvious and simplest way to exploit this is to run one "fake" query before your users are let loose on the system; that would mean you suck up the 1800 ms wait and your users get the sweet 400. Unfortunately, this will only work if all queries are the same, i.e. if everybody requests the same report. If there are different reports and different data, the caches will be flushed for different data and it will take more time to load the new results.
In short: If you always had the same query, you could give really quick answers, but then you'd never be presenting anything new.
Carl Smotricz
2010-07-20 12:42:09
thx for the advise!i am not using a db but xml-files but the effect is the same.. a big part of the time of the first call goes to the xpath-query. did not expected this, since it looks so trivial.
martin
2010-07-20 13:25:43
Parsing XML is an incredible amount of work! How often does this XML change? You could set up a lifecycle listener which parses the XML into a DOM and stores that in the servlet session. Then queries will run XPath but don't need to open or parse the file. If the XML is occasionally updated, you could write another servlet that forces a re-parse.
Carl Smotricz
2010-07-20 17:31:29
Before you listen to me: Do some logging and find out which operations are sucking up time. My advice addresses the cost of file reading and XML parsing, but it's possible time is being spent elsewhere.
Carl Smotricz
2010-07-20 17:32:57