measure back-end store perf

[Zen 98052 <z9...@outlook.com>]

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

Re: measure back-end store perf

[Andy Seaborne <an...@apache.org>]

On 09/06/16 15:51, Zen 98052 wrote:
> 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

>
>
> Thanks,
>
> Z
>