DOs automatically cache in memory unless you set noCache: true

Setting no cache can be helpful if you are writing something that wont be read frequently

You do get charged for cached reads on DO though so it could still be helpful billing wise to cache it yourself and set noCache true

This was my counter DO I tested to 1000rps though:

ts
export class Limits implements DurableObject {
    private app = new Hono<Bindings>()

    constructor(private state: DurableObjectState, private env: Bindings) {
        this.app.post('/', async c => {
            try {
                const requests = await this.state.storage.get<number>(`Requests`) ?? 0
                await this.state.storage.put(`Requests`, requests + 1)

                return c.json({ requests: requests + 1 })
            } catch (error: any) {
                return c.json({ error: error.message }, 500)
            }
        })
    }

    async fetch(request: Request) {
        return this.app.fetch(request, this.env)
    }
}

I get some: "Request failed no route to host" for my go server 😢

using this script

🤷

Same for wrangler

you did not get these issues?

Nope works fine for me

They did work out more transparent pricing. I didn't end up doing with them because I felt it was too big a risk migrating all my data over to a new platform and an unknown database. We kept running into UI bugs and found one DB bug (or feature that didn't work the way I expected). I decided to cancel our Cloudflare server re-architecture and migration completely because of that and DO Storage not being easy to view without building something custom. I am shoring up our Firestore + Google App Engine solution we currently have.

I have ideas for trying a move to Cloudflare again in the future, but it involves creating a database abstraction on top of DurableObject Storage that mimics Firestore's hierarchy with collection/doc/collection/doc... where each collection (and sub-collection under a doc) would be a single DO. The problem I had with DO storage is there was no way (out of the box) for me to browse/query the data across my entire deployment, so this database abstraction would give me a master database with (in my system) users & projects and under each user & project doc would be their collections (a sub-database, located close to the user) with their data. This would allow the system to scale while allowing me to navigate through the data. And allow me to use secondary indexes where needed.

If I were building a new product from start, I would consider using Macrometa. I just didn't want to risk it with existing customers. With an offline-first app, it's very fast, so they wouldn't appreciate server issues when everything is working well for them already. 🤷‍♂️

I'm using operational transformation, so I store each operation to the database and store snapshots of the data in object storage (e.g. R2). I've not used y.js, but I believe it sends deltas to the server. You could store the y.js object to R2 and load it into memory when you get changes and apply them, sending changes out to other clients who need them. If you expect to get many updates a second, you might consider storing each delta to DO storage and setting an alarm to store the entire object to R2 after 30s or a minute of changes. If your DO shuts down, you've got all the data stored safely. The alarm can be sure to apply all deltas and commit the object to R2, then it can delete the deltas that went into it from DO storage so it doesn't grow unbounded.

Do you have any info on requests per second you can get? With 17ms duration time, is that about 58/second, or is that a naive way to calculate it?

The request per second per object is very very low for that specific project, I have an object per data center setup and the DOs are only called by health checks which run once a minute in every data center (the DO gets called twice per health check). The RPS you can get for DOs is very heavily dependent on what you are doing and how you spread out requests across objects. But if you look at this message: https://discord.com/channels/595317990191398933/773219443911819284/1067919549774700635 I did some load testing on a very simple DO that its only purpose was to increment a counter and it could handle 1000 RPS without any errors and keeping a 100% accurate counter. With the p90 latency being about 200ms (tracked from the requester perspective not the actual DO duration)

Thank you

not DOs dying for a second while im load testing

Anyone know what the cause of "Network connection lost" is? (i.e is my DO dying because of overloading or is the connectivity actually not working from the specific server I hit to the DO)

DO have cold starts right?

The script has to be loaded and the instance constructed before it can receive requests, if that's what you mean, yeah

I guess the most typical case is DO deployment, and the roughly once-a-week runtime update, and then prob. numerous internal reasons

DO deployments cause a different error message (one that actually states there was a new deployment)

"Network connection lost" is a client side error that basically means the TCP connection got disconnected. It can happen for many reasons since talking to a DO often involves talking over the internet, and typically means a retry is warranted.

Can I bind one durable object class to another? So a request flow could look like Worker->DO(class A)->DO(class B)

Yes, you can make calls from one DO to another

Do you know of an example of binding one to another? Or would they technically be under the same "worker" and just be references through the

env.{DO}

?

I do it the same way from one DO to another as from a regular worker to a DO, use env., create the stub, use the stubs fetch method.

is it possible to view and manipulate DO data via Wrangler? (kinda like KV)

It's not