Basic Record Layer query performance and caching strategies

#1

In getting up and running I’m seeing basic queries (inserts/lookups/queries) take about 30ms. I think this is an issue with the way I’m reusing (or failing to re-use) the instantiated recordStore instance. I’ve roughly followed the steps from the GettingStarted.md tutorial and I’m starting my queries like so:

FDBRecordStore.newBuilder()
    .setMetaDataProvider(recordMetaData)
    .setContext(context)
    .setKeySpacePath(path)
    .createOrOpen();

This call alone seems to take ~7ms or so. From the tutorial the “The FDBRecordStore object only has the lifetime of a single transaction”. Is it possible to cache some or all of this instantiation to reuse between transactions? Is there possibly something else wrong with my setup (I’m using a local development foundationdb instance)? Any general guidance around what kind of latency I should be expecting from simple queries?

#2

It seems I might have just missed FDBRecordStoreStateCache and the related methods. Would be great to get confirmation that that should handle most of my caching needs.

#3

Hmm, it seems that even when enabling the cache (and seeing a cache hit) I’m still seeing similar delays.

#4

agh, ok, I take it all back. if I run it outside of Docker For Mac all the numbers drop to low single digit ms. seems this is just an issue with running everything in a constrained vm

1 Like
#5

Ah, glad you were able to figure it out!

The other somewhat confusing thing about the MetaDataVersionStampStoreStateCache is that you have to set the option in the store header to make the meta-data cacheable, but if you saw a cache hit, then that worked. (But just posting here because others might run into a similar issue.)

1 Like