On 07/30/2013 07:18 PM, Mircea Markus wrote:
Adding infinispan dev and Martin.
I think it makes a lot of sense for QE to run the tests you suggested.
Sent from my iPhone
On 30 Jul 2013, at 17:56, Shane Johnson <shjohnso(a)redhat.com> wrote:
> I was looking at the code for this cache store the other day.
>
> I noticed that is neither a log structured nor a b/b+ tree implementation and it
lacks compaction. Maybe it is elsewhere or I simply missed it?
No, the storage does not need any search structure as it keeps all keys
with entry position in-memory, what is its major drawback.
> Have we run a long test (as in hours) with variable length
values? It looks like this implementation may be inefficient in that it would result in
numerous gaps (unusable free entries) if the values grow or shrink in size.
No, we
have not run such tests. Regarding the gaps - the implementation
always uses smallest fitting allocated block, if such block does not
exist, it allocates another on the end of file. It does not coalesce
neighbour free blocks but neither splits them.
In worst-case scenario with growing size of the entries used, yes, it
would leave old free blocks unused. But if the distribution of entry
size does not change this is not a problem in my opinion.
> Where the tests run on SSD drives? I'd think that this type
of random read/write would not be terribly efficient on an HDD.
Currently, QE
doesn't have any HW with SSD drives.
> Have we done performance testing using FileDescriptor.sync() and
have we considered using an AsynchronousFileChannel instead?
Not sure what are you
asking for - file syncing in tests was achieved by
calling FileChannel.force(false). You won't find the code for that, I've
just hacked it locally.
Radim