ah ok interesting

i'd expect alarms and fetches to both show up as requests

I will have to get creative and implement size counting everytime transactional

put

and

delete

is called per DO

but that is an extra write request that im being charged

I will look exactly how is that on my grafana... Maybe that was made wrong anyway, but i remember that i do the amount of data each day and plot a graph.

Yeah but its not on the

durableObjectsPeriodicGroups

query so currently you would need to query both invocations and periodic groups. GQL can do both which is nice but having to only get data from one would be nicer.

going back to the memory metrics question, I'm not trying to be a pain, genuinely curious exactly what action you'd take in response to an api that told you 2 DOs were on the same isolate and each using X amount of memory

I dont others, but because on my usercase the DO itself is inflating the memory (by download things from KV) i will just stop to do so and notify my parent DO to make another shard (i do N number of shards untill i consume all data)

so you don't want metrics, so much as a runtime API that lets a given DO know how close to OOMing it currently is

Okay, just looked here. I was wrong, so much things on my read and i miss remember that detail. I do use graphql to get other metrics, but per DO i do use a custom key that sums the content-size of each value, its not precise because is not the same that will be inside of our DO. My bad...

dw

Yes, for that particular use yes, i dont care exactly how much is, just want to know that i must not put more things on memory because im close to use all.

Any creative ways to put a storage limit on a DO ? The straight forward way is to get the current storage at runtime and decide to allow or reject, but that seems to be pain atm.

do you need a byte limit, or is a key count based upper bound sufficient?

Either is good, but would prefer bytes, this gives room for the users to play around the value sizes without worrying an upper limit and my costs for free plan users is more clear.

Aside from that I would still like API for getting storage per DO so I can charge for paid plan tho, altho for paid plan I have economic room for implementing an actual counter

if a DO per channel otherwise works for you, I wouldn't redesign things just because of an error. What's the actual impact of that error

Abruptly crashing the app in the middle of a stream and chat. We're creating a scrollable feature where users can scroll through different channels. But disconnecting and reconnecting websockets at those speeds is not feasible when using websockets.

what exactly did support tell you?

https://github.com/cloudflare/workers-chat-demo/blob/66f513acb23fd5acafbc2efba4385d1a1becd7fc/src/chat.mjs#LL213C13-L213C13 from the official workers-chat-demo...

controller.storage

doesn't seem to be documented anywhere -- guessing

this.state.storage

has taken over?

They just called the first arg controller instead of state in the constructor. You can call it anything you want.

ah i missed that -- makes sense

this.sessions = [];

if i define that in my constructor -- how persistent is that? only if other workers connect to that DO on that same id can access that while there is a websocket? suppose i send a request to this DO and update

sessions

since its just a request and it doesn't "hold" it, is it immediately erased if i send another request? this is relating to this: https://github.com/cloudflare/workers-chat-demo/blob/66f513acb23fd5acafbc2efba4385d1a1becd7fc/src/chat.mjs#L220

this seems to be a good answer https://discord.com/channels/595317990191398933/773219443911819284/1045255111506669578

"outcome": "canceled"

This error is typically caused by the client (browser) side of the connection closing it, and doesn't usually indicate a problem on Cloudflare's side. And looking into code 1006 further, it seems this is an error code non-specific to Cloudflare and indicates an abnormal connection close on the end of the client. For example there are general internet resources like https://stackoverflow.com/a/19305172 which describe this.

This thread moved along quite a bit while I was offline, but my use case is similar to @Wallacy. I want to use it during development to estimate how likely a design decision I make is going to lead to OOM errors in production. I might turn it on in production and create some artificial load. Can a single instance support 1000 rows of something if it has the memory all to itself or 100,000 of that something? How often do different instances of the same DO code share memory? What's the maximum number of instances that do this sharing? These are the sort of questions that would change my design decisions. I would relax a bit if you were to tell me that at most 5 instances will share memory and the memory consumption in node.js is approximately the same memory consumption you'll see in prod for that same data structure and quantity.

if you're trying to estimate the size of a given datastructure, there is a feature request for it, but in the meantime

v8.serialize(foo).length

in a node shell is reasonable estimate at least for storage size. If you're trying to estimate how much memory a whole app uses, local testing with minflare is probably your best bet. You can tell whether instances are sharing memory in production by just checking / setting a global variable in the constructor (if it was already set, you're sharing). There is no maximum number of instances that can share memory

similar to what I asked wallacy, what action would you take if you did have a runtime api that told you a given DO was close to the memory limit? Stop sending requests to it?

the websocket hibernation api is available in open beta now https://developers.cloudflare.com/workers/runtime-apis/durable-objects/#websockets-hibernation-api-beta

anyway to update the state without getting and putting?