Database bandwidth
My database bandwidth has risen very fast and I can't tell why.
This doesn't include files does it?
I'm looking at the dashboard and I can see the amount of function calls but not the size.
How would you reccomend finding out what the culprit is burining through my Database Bandwidth?
19 Replies
I've upgraded to a paid plan but I've burnt through 800mb in a day of dev when in the past it was at most 150mb last week.
Do actions count towards this? I see there is action compute so I assume it's seperate
Based on this dashboard I have read /write 1.81GB worth of 1.62MB of data?
@Michael Rea hey! I'll DM you so we can investigate this and I can get your account information
we have much better usage reporting for bandwidth coming out soon, but it's not shipped quite yet unfortunately
in the mean time we can look it up in our systems to help you debug
That would be amazing ❤️
I’ll mark this as resolved, interested if anything generic comes out of it to share
Looks like it's a call on my end getting hit.
Looking forward to a bandwidth dashboard so I can see myself what's causing it
Yep. @Michal Srb has some dashboard changes we’re releasing soon that give you more info about this.
I think it's that for each item the UseQuery is returning in the UI it's calling another query.
So maybe each time an item is added is calling again for all of them.
There are probably ways to optimize this we can help you with
The more your queries are cache hits, no db bandwidth is used.
Hmmm, maybe not then. So if the underlying data is not changing and a query is made it should not use any bandwidth.
I'm making a choose your own adventure game.
I have storyNodes and choices for each of those nodes.
This is the query that seems to be having the issues
I'll post if I figure out why it's not caching these
I have a question
If you call
await ctx.db.get(choice.parentStoryNodeId);
Is that cached?
It's only cached after the first time it's called
Can you set up the
byStoryNode index? That will definitely lower the bandwidth, as the non-indexed collect() reads the whole table every time.ahh okay, yeah will setup indexes
I'm also changing my schema so that the choiceIds are on the storyNodes
I was unaware that the whole Db was being read, I assume thats what the cause is then.
Still wrapping my head around the caching, I think I'm starting to get it though.
So because of the way it works I think I'll aim to have very narrow queries.
So instead of getting the whole storyNode object (which will re-run if a something changes on it)
in my UI client maybe I should have a useQuery for getting specific fields like the storyContent (which won't change)
This will work for now. I’m the future we want to support server-side sub-queries with caching so you don’t have to push this stuff to the app to solve this problem.
Aweseome, sounds like you guys have some cool stuff cooking.
Ah yes. Your comment is very astute. Currently when it doesn’t use the index, it’s scanning every document for every query. Changing it to an index will only fetch those documents