> On Sep 25, 2019, at 08:57, Joan Touzet <woh...@apache.org> wrote:
> 
>> [*]: I don’t want to come off as alarmist; when I say this operation is 
>> “expensive” I mean it might take a couple of milliseconds depending on FDB 
>> configuration, and FDB can execute 10s of thousands of these per second 
>> without much tuning. But it’s always good to be looking for the next 
>> bottleneck :)
> 
> This is the really important data point here for me. While Cloudant
> cares about 2-3 extra ms on the server side, many many MANY CouchDB
> users don't. Can we benchmark what this looks like when running
> FDB+CouchDB on a teeny platform like a RasPi? Is it still 2-3ms? What
> about the average laptop/desktop? Or is it only 2-3ms on a beefy
> Cloudant-sized server?

For single-server deployments, this would become much less of a concern.  The 
expensive part of this operation is broadcasting to all of the other 
transaction processing nodes and waiting for a response on what the most 
recently committed version is.  In a single-server cluster, there’s no network 
latency.  In a single-process cluster, this becomes a trivial operation.  It 
only becomes expensive when needing to scale out across multiple servers.

My local laptop (macOS) has FDB from the installers provided on the website, 
which creates an FDB “cluster" in the default developer “everything in one 
process” setup.  On a teeny platform like a raspberry pi, I’d expect one would 
run the same way due to memory constraints.

This is also pretty simple to benchmark:

```python
import timeit

t = timeit.Timer(
        setup="import fdb; fdb.api_version(600); db = fdb.open()”,
        stmt="tr = db.create_transaction();  tr.get_read_version().wait()”)

print(“Time per GRV: %s seconds” % (t.timeit(10000) / 10000.0))
```

$ python /tmp/potato.py
Time per GRV: 0.000160318207741 seconds


So I’d probably only worry about the smaller setups if someone is going to be 
running a single CouchDB+FDB cluster across many raspberry pi or across many 
laptops, which sounds like a less likely setup?

Reply via email to