Usage calculation
Hi, I would like to check how usage is calculated for database bandwidth.
Suppose a few clients send the same query to a function - is the output of the function cached, or does it incur row reads for each time the query function is invoked?
is there any way i can debug which function is causing the large amount of consumption of read bandwidth so that i can optimize the usage?
5 Replies
If multiple clients send the exact same query, then it will be cached and won't incur row reads. To be the same query it must have the same arguments, same (or missing) auth, not use
new Date() (or be within a few minutes of the cached result), and the underlying data read cannot have changed. You can see if a query is cached in the dashboard logs for the deployment.
To see what function is using lots of bandwidth, check out the usage page https://dashboard.convex.dev/team/settings/usage -> Functions breakdown by project -> Database bandwidthConvex Dashboard
Manage your Convex apps
thank you for this, I completely missed the function levels tracking for bandwidth and using logs. super helpful.
also, for
usePaginatedQuery, I think there is an issue regarding caching, because the client seems to generate an id for each pagination session, but this seems to prevent caching.
so when a page component unmounts and remounts with what is effectively the same query to the user, it seems to never get cached.
I think this is truly the issue because across app restarts (close the app and open again), the cache seems to be hit because the id counter is reset.
think this effectively forces a refetch every time to make sure data is fresh. but I don't think this solves the root of the issue.
https://github.com/get-convex/convex-js/blob/250cf7985f5e69817e2b51d4558c166940b870c5/src/react/use_paginated_query.ts#L373-L400GitHub
convex-js/src/react/use_paginated_query.ts at 250cf7985f5e69817e2b5...
TypeScript/JavaScript client library for Convex. Contribute to get-convex/convex-js development by creating an account on GitHub.
also one interesting thing I found - I was using the
luxon DateTime object for conversions within a query, and the cache was always missed. I have a feeling it uses something relating to new Date() to get info about the environment.
This results in the cache always being purged when running code within a query (referring to a normal query here, not a paginated one).
I think it might be nice to have some sort of message to warn users where queries fundamentally cannot be cached, or even require explicitly failing the build unless a parameter is included (e.g. call a method ctx.disableCache() at the start of a query).This is great feedback that might get better visibility in the #support-community channel, or you can chime in on https://discord.com/channels/1019350475847499849/1197183648517083136/1197183648517083136
great! let me move this discussion there. thanks @Lee