Your ideas a valid, but not reflecting out tests. We narrowed down our test: reading the very same keys (1000 of them in tx), keys are the only one in the database (~1mb of kv), memory storage. Added three more FDB stateless processes (running on macbookpro still, 6-8 cores). We also built a simple golang benchmark that equals to NodeJS one to rule out JS part: it turns out that performance is ~10% less in nodejs, but it is more reliable and we found one minor improvement that makes everything equals to golang performance.
This is clearly some kind of “anti-pattern” benchmark, but we are basically trying to achieve one of the reference benchmarks:
Start 100 parallel clients, each doing:
Loop for 1 minute:
Start a transaction
Perform a random 1000-key range read
Result: 3,600,000 keys/second
The main difference is that we want to get this in a single “instance” of our app.
As our research shows that network thread is indeed shared across all clients in the same process, but we actually tried to run everything in parallel and we got ~20x performance degradation.
We literally just started 5 parallel instances of our app each with one client and we got 32 sec per instance instead of 1.5sec.
Again, reusing read versions yield same results.