[infinispan-dev] Cachestores performance

[Radim Vansa]

| >>> 
| >>> My worry about Karsten's impl is writing actually. If you look at the
| >>> last performance numbers in [2], where we see the performance difference
| >>> of force=true and force=false in Karsten's cache store compared with
| >>> LevelDB JNI, you see that force=false is fastest, then JNI LevelDB, and
| >>> the force=true. Me wonders what kind of write guarantees LevelDB JNI
| >>> provides (and the JAVA version)…
| >> 
| >> ^ Oh, Radim mentioned this topic already in a previous post. LevelDB JAVA
| >> library seems to provide force=true equivalent logic.
| > 
| > Actually Radim, maybe I misunderstood your comments earlier, but what is
| > this mmap/FileChannelTable stuff. Here's what I'm seeing:

Ok, the leveldb.mmap flag was about using (FileChannelTable + FileChannelLogWriter) OR (MMapTable + MMapLogWriter). And we stick to the FileChannel* stuff.

| > 
| > LevelDBCacheStore implementation calls DB.put without any options [1].
| > Underneath, iq80's DbImpl calls the other put with a newly constructed
| > WriteOptions instance, whose sync parameter is set to false. The default
| > in Fuse's JNI implementation seems to be sync=false too [2].

Sorry, I've really mixed things here, FileChannelLogWriter really uses force(false) only if it is explicitely requested, therefore, in my tests it does not.

| > 
| > So, it might be interesting to re-run the test after changing line in [1]
| > to pass a new instance of org.iq80.leveldb.WriteOptions instance with
| > sync=true… WDYT?
| > 
| > Btw, at least in the LevelDB Java implementation, FileChannelLogWriter is
| > the one that is using this sync parameter, and not
| > FileChannelTable. I'm not sure about the relationship of these two yet, but
| > from I see in the code, DbImpl uses FileChannelTable as a tableCache (what
| > the heck is that? no docu) and that doesn't seem to be touched when an
| > entry is put.
| > 
| > What seems to be touched when putting an entry is the log, and the
| > memTable, which is a in-memoyr cache of keys to slices, and the log is
| > where you write the slice.
| 
| ^ If my suspicions are correct, then none of the LevelDB implementations
| (neither Java nor JNI) are forcing writes, in which case Karsten's cache
| store could be a winner even in the write area (really??). Just looked at
| Google's WriteOptions struct, and sync default value is false too [1].
| 
| So, we definitely need to construct an instance of WriteOptions and pass true
| in the sync parameter, and do the put calls with that. Then compare the
| results…
| 

Aye aye, will do.

Radim