Discussion:
measure back-end store perf
Zen 98052
2016-06-09 14:51:59 UTC
Permalink
Hi,

I am using our own custom db to store the triples data, and I'd like to put the code to measure net perf on how long it takes reading/writing to the store.

For update operation, since I subclass DatasetGraphBase class (which has startRequest and finishRequest functions), I can put the start/stop time in those functions.

However, for query operation, I subclass from GraphBase class, which has graphBaseFind function, which returns iterator.

Do you know where can I put the start/stop time in that case? Or does Jena already have the code to log the perf that I can enable?


Thanks,

Z
Andy Seaborne
2016-06-10 14:56:36 UTC
Permalink
Post by Zen 98052
Hi,
I am using our own custom db to store the triples data, and I'd like
to put the code to measure net perf on how long it takes
reading/writing to the store.
For update operation, since I subclass DatasetGraphBase class (which
has startRequest and finishRequest functions), I can put the
start/stop time in those functions.
However, for query operation, I subclass from GraphBase class, which
has graphBaseFind function, which returns iterator.
Do you know where can I put the start/stop time in that case? Or does
Jena already have the code to log the perf that I can enable?
You'll need to time the execution of the iterator - and not the iterator
from the graph but the overall SPARQL result iterator.


This should be not only to consume the iterator but also to touch every
slot in a binding if necessary,. For example, results backed by TDB do
not fetch the node for the column in the results unless it is needed
(e.g. count does not need it).

arq.query has some timing code.

As does Fuseki2.

Both can work from assemblers.

Andy
Post by Zen 98052
Thanks,
Z
Loading...