Question: Pricing page for Wix Studio mentions that there’s a cap of 500,000 read requests for the recommended Plus plan. Is there anywhere that I can track how many read requests users of a site have used up month-to-date?
Product:
Wix Studio
What are you trying to achieve:
Get clarity around how to track read requests so I could use that information to structure data model and write code in most efficient way to avoid reaching the read quota and having my users experience service interruptions.
What have you already tried:
Going to the Monitoring section of Developer Tools. The numbers mentioned there seem to be a mix of read and write requests and is grossly exaggerated.
Additional information:
I have been developing a site and testing it with a single user. Heavy use of the site generates about 1,000 read requests per user per day. If a single user will use a site for 15 days out of the month, that’s 15,000 read requests per user per month. With 500,000 read requests quota, that means that my site can handle only about 33 active users per month which can’t possibly be right.
Let’s say I’m grossly overestimating average user’s use of the site. Let’s say average user will spend only 5 days on the site out of the month and make only 500 read requests per day. With 500K read requests cap, that’s still about 200 active users per month max.
Wix has to have clients that have platforms that host thousands of active users that make hundreds of thousands of read requests per day.
That makes me think that the numbers I see in Monitoring section of Developer Tools include a whole lot of read requests that don’t actually count towards the 500,000 record count quota. Either that or I’m missing something. In either case, does anyone know if there’s a way to tell how many read requests users of a site have used out of the allocated monthly quota in Wix Studio?
That is the problem. I can’t. I can guess, but there’s nothing that I found which would tell me things like:
Number of read requests a page is making each time it is loaded.
Number of times a page was loaded.
Number of read requests that were made as a user was interacting with a page.
Number of read requests a function is making each time it is called.
Number of times a function has been called.
Which page is calling which function.
Which user interacted with a page that resulted in read requests being made.
Which actions users take to generate read requests.
If those types of analytics were available, it would be easy to tell where the requests are coming from and what, if any, optimizations can be done.
Without those details, I have the same question as you do. I see about 1,000 requests per user per day and I have no clear way to see how that number was calculated.
I’m not even sure that the number I’m seeing is accurate read request count. It could be something else.
That brings me to this post with the question “How to track read requests quota usage”? Or put differently, “is there a way to see how many read requests were used month-to-date and how many read requests are remaining out of the available quota?”
It won’t answer every question above but looking at the “Top data requests” shows which Collections and operations are causing the majority of the reads.
The “All data requests” chart can also be filtered by collection and data operation to give the number of requests from specific collections/operations that are occurring over time.
Thanks for the details! I have couple of follow up questions.
CMS Making Read Requests
The second sentence in Data Requests section of Working with the Monitoring Dashboard page mentions that:
“This includes requests from your site’s code to the Wix Data API as well as requests made by the Content Management System (CMS)…”
Would you know what requests are made by the CMS and under which conditions?
Count Operations
The Operations column in my Top data requests table looks similar to the one you posted in your reply. About half of my requests are associate with count operation.
I know that I don’t use count() function in any of my custom functions but I still see high number of count operations.
I’m guessing that find() function might be generating double read requests - one for find operation and one for count operation - but I’m not sure.
Do you know where the count operations may be coming from and whether or not find() function generates both find and count operations?
Following up on this question. The CMS does make a read request to display data and it makes a request to count() to display the total number of items in a collection.
I wanted to clarify this as well. There are no longer monthly quotas on reads/writes. The only monthly data-related quotas are on CMS storage; measured in rows.
That’s fantastic news! Thanks @anthony! I appreciate your research and help with this!
The key takeaway then is that with the monthly quota gone, it’s no longer relevant how many read/write requests total were made. What’s important is frequency of requests per minute.
To close this discussion, were able to find anything on find() function making count requests? I see that the documentation for find() function mentions that there is omitTotalCount option that can be set to true.
Is it true then that if the find() function is used in a code and omitTotalCount option is set to false then the find() function makes double read request - one for find operation and the count operation?
I checked on this and a call to find() will not trigger a double counting count() request no matter how this option is set (true, or false). Setting it to true is only intended to speed up queries in cases where you don’t need a count of items in the result.
That’s good to know. I guess the best explanation for count operations are coming from me visiting CMS section in the management console and it recounting number of items each time CMS page is viewed/refreshed.
In any case, you’ve more than answered the question and with the monthly quota gone, there’s no need to worry about total monthly read requests which take a whole lot of stress off my shoulders. Thanks again for looking into this and for all your help and insights!
