Re: [update] piggybank performance profiling
>> I was able to get my performance up by:
>> ]] modifying my schema so that the user facing actions motly result in
>> queries that have subject provided (mostly by adding a reverseCached
>> predicate).
>> ]] limiting the number of and moving most of the reverse queries to
>> return results to the interface asynchronously
>>
>> What did not work, was loading part of data to an in-memory store. I
>> am guessing this is because the in-memory store is also indexed by
>> subject - though I did not spend as much time on this approach since
>> in my case the above two cases showed very good results without more
>> tweaking needed.
>
>
> Thanks dude, you saved me a few hours of trying the memory store instead.
>
> I'll see if I can do the same for PB... I have to understand what
> queries do what.
The way I did this was to log:
] Delays of RdfRepository.getStatements and StatementIterator.next
dumped on call to StatementIterator.close
] Dump delays on call to RdfRepository.hasStatement
Moved the logged data (get/has, delay, subj, pred, obj) into a pivot
table in excel to help analyze the data - the predicated that I needed
to optimize where fairly obvious then.
Vineet
Received on Sat Sep 03 2005 - 18:04:32 EDT
This archive was generated by hypermail 2.3.0
: Thu Aug 09 2012 - 16:39:18 EDT