Explaining Dashboard Query Ops

 Why do I see so many query ops on my Dashboard/Shell even though there isn't much going on ?

This is a question that we see comes up quite often. In this article we will break down what happens when you get into the Dashboard and what each operation amounts to in terms of ops.

Calculating Read and Write Operations

Every call to create, read, update, and delete Fauna Indexes and Documents requires a cost in the form of Read, Write and Compute operations. Storage as well, but that is harder to measure on a query-by-query basis, and we’re focused on Read and Write operations here.

One important thing to understand here is the nature of Fauna's schema. That is, Fauna’s Collections, Indexes, Functions, Roles, Databases, Keys, Tokens. etc. are all kinds of Documents. That means that reading, writing, creating, deleting schema also costs read and write operations.

If you have created a Database, a Collection, and added just one Document from within the Dashboard, then you’ve already cost yourself at least 3 Write Ops and at least 60 to 80 Read Ops. Let’s get into the details of why that is next.

Check out the docs Billing page for additional information on how costs are calculated. At the end of the docs page, it shows you how you can inspect the response headers to view how many operations a query costs. I will do that to walk through the cost of some operations.

Dashboard Operations

Navigating the dashboard costs read operations to fetch your information the same as it would if you queried for it yourself. Just about every action you take on the dashboard will require read operations.

So far we considered these actions:

1. Sign up and log in
2. Create a new database
3. Create a Collection in our new database
4. Create a Document in our Collection

So what has actually happened so far?

1. Sign up and log in

When you sign up and log in for the first time the dashboard requests the list of all Databases for your account. The Dashboard also brings together all of your data across the different Region Groups, so it actually has to do this 3 times (for Classic, US, and EU).

• Query: Paginate(Databases(), { size: 1000 }).
  • 16 Read Ops * 3 = 48 Read Ops
  • 0 Write Ops

NOTE: Paginating the list of Schema, including Collections, Indexes etc. works on internal indexes with 8 partitions, so it costs at least 8 Read Ops to query them. Querying Databases requires 2 internal Index reads, so it costs 16 Read Ops. See the Billing docs for more information.

2. Create a Database

From the main page, you click the button to create your first database.

Once the database is created, the Dashboard will load the DB Overview screen, which includes a list of the database’s Collections, Indexes, and child Databases

3. Create a Collection

From the DB Overview screen, you should now see an invitation to “Create your first Collection”. So you click the “Create Collection” button. You are taken to the Create Collection screen, enter the information and click “Create”

Once the Collection is created, the dashboard loads the Collections screen and displays the details for the first Collection in the list. In this case, it’s just the one you created, but the dashboard doesn’t know that. In order to display this page correctly it needs to:

• List all of the Collections in your database
• For the first Collection found, Get and list the first 50 Documents

Listing all of the Collections now costs 9 Read ops. That’s 8 for the Paginating the Index, and 1 more for actually fetching the users Collection.

The Documents function works on a built-in index with no terms, so reading the list of Documents in the Collection also costs 8 Read Ops, for now, and will cost more once we add user documents. (see the Billing docs)

4. Create a Document

The Collection detail screen tells you that there are no documents yet, so let’s create one! Click the “New Document” button. Fill out the new-document form and click “Save”.

Once the Document is created, we are taken to the Show Document screen and the Dashboard requests the latest version of the Document.

Having inspected the new Document, let's add one more step. Navigate back to the Collections screen.

This will again list all of the Collections in the DB, and for the first Collection list the first 50 Documents.

The cost of viewing all of the Documents for the users Collection has increased to 9. This is because we first Paginated the Index (for 8 Read Ops) then used Get once to retrieve our single Document.

Tallying everything up so far

What was the cost of going through this in the dashboard so far?

• Read Ops: 116
• Write Ops: 3

It feels like we have done very little so far, but remember that the Dashboard has been presenting you with more information to provide the user experience it was designed for. Every time you navigate or refresh your browser, the dashboard requests updates from the database. It is tempting to suggest the information should be cached for better cost and performance, but the tradeoff would be to not receive the latest information, and that would be too disruptive to the user experience.

Rules of thumb for dashboard operations

• Every time you visit the Home page, expect 48 Read Ops
• Every time you visit a DB Overview page, expect 32 + [# of Collections] + [# of Indexes] Read Ops
• Every time you visit the Collection details page, expect 8 + [# of Documents] Read Ops
• Every time you click the Collections nav button, expect 8 + [# of Collections] Read Ops, plus the cost of loading the first Collection’s details.
• Functions, Keys and Roles are also plain old Documents underneath, so browsing the other pages will have required costs as well.

Monitor these operations in your browser

All of these requests are made directly from your browser to fauna. As you navigate around the dashboard, you can monitor the traffic in your network tab to see what requests are being made and how much they cost.

You’ll see the FQL protocol in the request body.

And the cost in the response headers.