| >>> | >>> 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 _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
