Read ops/pricing

Just looking for some clarification for the usage figures I’m seeing in the dashboard here.

The main “users” collection I have in this DB, comprises around 220 documents, and I’m very confused as to how I’ve allegedly amassed such a large amount of read ops on such a small collection. Checking the JSON file I exported from MongoDB Atlas, the size of that collection is 52kb.

Is this from creating indexes? Simply clicking on a collection in the dashboard? Also, I rarely use the shell, but when I do, my queries to said indexes are all coming back as 1 read op, and the figure for the actual back end doing the querying seems about right.

Is this an expected overhead when setting up a project? I’ve basically just started testing this system out with a small personal project, with a view to moving an absolutely massive project over to it if it pans out, but I’m quite concerned with these figures and would love some clarification before I look at moving on to a paid tier.

Also, just checking, the largest query I have is to an index to get all users, which shows this much data used:

Screenshot 2021-03-30 193812

Whenever you involve an index, index entries need to be read. Fauna typically partitions indexes to improve performance, so there is one read operation per 4k read (or portion thereof) per partition.

A collection index, which has no terms or values defined, and the internal index used by the Documents function, has 8 partitions. So, reading a single page of index entries incurs 8 read operations.

Billable operations are described in detail here: Billing | Fauna Documentation

Note that the greyed-out metrics in your screenshot are background Dashboard queries.

However, we recently identified a bug involving background queries whenever the Dashboard loses/gains focus. We just published an update that the notably reduce those metrics.

Let us know if you still see read op usage that seems high over the next week or so.

@ewan thanks for the reply, could you please explain what you mean by background queries? I’m not able to find anything searching for this term.

Does simply having the dashboard open cause any of these read ops to occur?

If I click on “indexes” but don’t perform any search, are any “background queries” occurring?
I presume that if I click on “collections” since it automatically shows the first entry, some read op occurs here, but an index doesn’t appear to do anything unless I actually enter a search term.

This really seems like a ridiculous amount of read ops for such a tiny amount of data, so I’d really like to know what to not click on in the dashboard, because clearly something is causing this to occur.

I’m making a lot of queries from my code, and that seems to show a tiny amount of read ops, compared to dashboard/shell etc, which I am doing very few queries from, so I’m pretty confused as to what’s happening here. Are these “background queries” somehow related to the queries I’m sending from my code?

1 Like

Hi @scallensc. I’m sorry for this inconvenience. Please see this topic as well for more information: Mysteriously High Read Ops - #3 by summer

We have released a fix that we hope has resolved this. While dashboard interactions do still accrue some read ops, we hope that it is minor. Please let me know if that does not appear to be the case.

“Background queries” refers to the Dashboard’s attempts to show up-to-date views while navigating its interface. The bug that was recently fixed caused a view refresh whenever the Dashboard page in the browser lost or gained focus. That could significantly boost the number of read operations for desktops that have an “autofocus” feature enabled, or if you cycle browser tabs frequently.

I’ve had a browser tab open on the Dashboard for several hours now, and even though I have modified documents in the currently-displayed collection multiple times (via fauna-shell, not the Dashboard), the view has not updated.

You should now only incur Dashboard read ops by interacting directly with the Dashboard, e.g. clicking on the Collections, Indexes, Functions tabs, click on the detailed view for a document, etc.

If you continue to notice unexpected read/write operation counts, do let us know.

If you prefer, you could use fauna-shell to interact manually with your database. It’s a command-line shell for executing queries, and there are no implicit queries (just the ones you write).

I am having the same issue and almost left Fauna after praising the platform for a long time. Please fix this as I already told my team to look for a new database.
I was racking read ops by the thousands for just checking to see how functions works or just creating a key.
Not good at all as we have spent hours looking for other options before I came to this forum.

As mentioned, a fix has already been deployed.

I am having the same problem.
Yesterday, 28,890 readings were made on the dashboard.
It is always open in a tab, but I never use it most of the time.

It has been deployed as you said but we have not seen any difference?

1 Like

The fix that we deployed prevents the dashboard from running queries to update the current view whenever it loses or gains focus. No adjustments have been made to already-counted metrics.

Are you still incurring read ops at the previous rate?