Fauna DB latencies unexpectedly slow

We are using faunadb combined with cloudflare workers but unfortunately find it pretty slow.

We are using the classic option for database and have the client configured like so:

const faunaClient = new faunadb.Client({
  domain: 'db.fauna.com',
  secret: FAUNA_SECRET_KEY
});

An example query which gets records from a collection:

return faunaClient.query(
    Map(
      Paginate(
        Documents(Collection(collection)),
        paginateOptions
      ),
      Lambda(x => Get(x))
    )
  );

This collection has around 20 records in and these are the times for getting said collection:

GET /v1/users?limit=2 200 OK (974.23ms)
GET /v1/users?limit=2 200 OK (903.74ms)
GET /v1/users?limit=2 200 OK (1451.97ms)
GET /v1/users?limit=2 200 OK (1228.47ms)
GET /v1/users?limit=2 200 OK (236.18ms)
GET /v1/users?limit=2 200 OK (102.01ms)
GET /v1/users?limit=2 200 OK (567.96ms)
GET /v1/users?limit=2 200 OK (490.67ms)
GET /v1/users?limit=2 200 OK (302.76ms)

Am I doing something wrong or are these times expected?

An example for just retrieving one record:

  const user = await faunaClient.query(
    Get(
      Match(Index('users_search_by_email'), email)
    )
  )

GET /v1/users/331905953155777099 200 OK (386.23ms)
GET /v1/users/331905953155777099 200 OK (368.34ms)
GET /v1/users/331905953155777099 200 OK (298.62ms)
GET /v1/users/331905953155777099 200 OK (96.77ms)
GET /v1/users/331905953155777099 200 OK (396.50ms)
GET /v1/users/331905953155777099 200 OK (247.14ms)
GET /v1/users/331905953155777099 200 OK (175.26ms)
GET /v1/users/331905953155777099 200 OK (146.29ms)
GET /v1/users/331905953155777099 200 OK (313.30ms)

And finally if I create a record:

return faunaClient.query(
    Create(
      Collection(collection),
      {
        data: userBody
      }
    )
  );

POST /v1/users 201 Created (615.84ms)
POST /v1/users 201 Created (419.30ms)
POST /v1/users 201 Created (407.91ms)
POST /v1/users 201 Created (144.86ms)
POST /v1/users 201 Created (836.91ms)
POST /v1/users 201 Created (465.37ms)

Right now I am using the free plan but plan to upgrade to the paid plan. I understand that the queries should be slower due to the strong consistency but I can’t seem to match the expected times on faunas website:

Latency if I don’t make any queries:

GET /v1/users?limit=2 200 OK (7.54ms)
GET /v1/users?limit=2 200 OK (1.61ms)
GET /v1/users?limit=2 200 OK (1.62ms)
GET /v1/users?limit=2 200 OK (1.42ms)
GET /v1/users?limit=2 200 OK (2.37ms)
GET /v1/users?limit=2 200 OK (2.02ms)
GET /v1/users?limit=2 200 OK (2.16ms)

Any ideas what I may be doing wrong?

Hi @TOKEN_HOUSE , and welcome to the community! :wave:

We have your support ticket and are investigating. I will follow up there to get more details about your account and the location from which you are making requests.

Fauna’s “Classic” Region Group is hosted in the EU, Eastern US, and Western US. While cloudlare has many servers at the edge around the world, your requests still need to get to one of Fauna’s hosts.

There’s a blog from our VP of Engineering that goes into more detail how we calculate the latencies displayed at status.fauna.com, and also how you can consider estimating your own latencies, depending on where you (or your users) are in the world.

Hi, thanks for the reply!

These times were actually generated locally from within the United Kingdom in London. The code wasn’t deployed to cloudflare.

Okay. Thanks, for the additional context. To continue the investigation we’ll need some more account info, so I will reach out in the support ticket.

Hi @TOKEN_HOUSE. After some more testing, we want to make sure that your testing has accounted for time required for TLS handshakes.

Please see another recent topic, here: Expected read latency from California on Classic Region Group?

If you can ensure that the Fauna client is reused in your application, then the TLS handshake can be insignificant in general to the latency of your requests. But if you have to establish a new connection for each request, then you will add maybe 100ms or more for every request.