Versionstamp performance

I’m hoping to get a bit more of a formal understanding of versionstamp performance. Currently, I’m not 100% clear how versionstamps are generated and how their invariants are enforced.

For instance, it every write transaction to the database utilized the versionstamp, would it effectively be single-writer performance (because those versionstamps would need to be synchronized) or is there some mechanism through which transactions can be committed concurrently while maintaining the version stamp’s monotonically increasing property?

1 Like

Versionstamps are generated on the proxies as we are preparing to send the transactions off to the resolvers for conflict resolution. At the point where versionstamps are added, we already have the commit version (which is unique to a proxy) and the transaction number within the version. This is true even if you aren’t using versionstamps, so there shouldn’t be any extra synchronization cost.

I think the only cost you’ll incur on the proxies for these mutations is that you have to copy the actual versionstamp into place over the placeholder bytes. To be honest, I don’t know for sure how much more expensive that is than just issuing regular sets, but it’s probably not dramatically different. If you run a test to compare the two, I’d be interested to hear the results.

Also as a side note, the proxies are a scalable component of the system. If you find that you’re taxing the proxies, you can add more of them to distribute the load.

1 Like