On 12/07/12 10:14, Andy Seaborne wrote:
On 11/07/12 20:57, Michael Brunnbauer wrote:
but it could be the transaction overhead
+1
Not that simple ... another prime candidate is not managing connections
in the same way e.g. connection caching as is managing the dataset with
open/close. These are Fuseki things.
The TDB transaction overhead per se is a few wrapper objects (to enforce
read-only) and in TDB-only tests, has not shown up as significant in a
setup like your as I understand it.
Just to check details: what's the config file for Fuseki that you are
using or these tests?
Andy
Michael sent me the config file - the only potentially interesting point
is that the server has 4 large datasets all attached to the one
instance. This might cause the OS to get unhappy - but maybe not.
A simple test of transaction overhead put the cost of a read transaction
under 1ms (raw TDB) so that does not in itself account for
That puts it, at worse, comparable to the cost of a simple query.
For 10K transactions, 3.2s; for 10K transactions and simple query 5.7s.
(and there is maybe some speed-ups as I see a surprising cost showing up
in YourKit but even that is 20% of the total time of my transaction
churning so this is not explaining what Michael is seeing)
I can't reproduce the situation: I do really need a similar setup
because what's going on is not jumping out at me. The performance tests
I've done do not show the effect you have.
The things to try that occur to be are to simplify the situation:
1/ Run with only one dataset on the server
2/ Change the workload: do multiple calls of each query , so do
q1,q1,q1,q1,q2,q2,q2,q2, etc
Andy
