high runtime fees

[martinkallstrom]

Loving this project, thanks for publishing!

Have you found a way around this issue? jamsocket/y-sweet#203

[naporin0624]

No specific workaround is known.
One thing I can say is that you should use HibernationAPI.

I am getting more requests than are covered in jamsocket/y-sweet#203, but the connection time has not increased to this point.

I will respond to what I know about what is being discussed in this issue

• The odd usage time of DurableObjects
• The cost savings of using the Hibernation API
• Duration time even after WebSocket closes

DurableObjects' odd usage time

Here is the LastWeek usage of my public https://yjs.napochaan.dev.

What you can save money by using Hibernation API.

If you prefer, use state.acceptWebSocket() instead, which will stop incurring duration charges once all event handlers finish running.

https://developers.cloudflare.com/durable-objects/platform/pricing/#billing-metrics:~:text=If%20you%20prefer%2C%20use%20state.acceptWebSocket()%20instead%2C%20which%20will%20stop%20incurring%20duration%20charges%20once%20all%20event%20handlers%20finish%20running

It is described like this. y-durableobjects supports Hibernation API, so it is less expensive than y-sweet.

Duration time even after WebSocket is closed.

In my environment the connection appears to be closed.
It may happen when Hibernation API is not used.

DurableObjects billing documentation

See here
https://developers.cloudflare.com/durable-objects/platform/pricing/#durable-objects-billing-examples

Examples 2, 3 and 4 are very expensive. The number of people using the system and the amount of time they are connected may lead to high bills.

[naporin0624]

I had no knowledge of DurableObjects' high billing. I have not applied y-durableobjects to production, so this kind of input is very helpful.

[CiskaLV]

I just set it up and in the 30min it has been up already used like 20k request im using it with tiptap rich text editor and the y-websocket Provider mybe im doing something wrong any suggestions.

[naporin0624]

@CiskaLV

Looking at https://developers.cloudflare.com/durable-objects/platform/pricing/#compute-billing, the cost for Requests is significantly lower compared to Duration. While a sharp increase in Duration would require cost mitigation strategies, Request volume shouldn't be a concern from a pricing perspective.

Regarding the request surge, since these are regular HTTP requests (not WebSocket connections), I'd recommend implementing request filtering at the Worker level before proxying to the Durable Object. This would help reduce unnecessary load on the DO instance.

Additionally, please note that RPC usage can increase the Request count as stated in the documentation:

Each RPC session is billed as one request to your Durable Object. Every RPC method call on a Durable Objects stub is its own RPC session and therefore a single billed request.

If you're using RPC, please check if there are any RPC calls from Workers that are being made without proper filtering. This could be contributing to the increased request volume.

[CiskaLV]

@naporin0624 Ty i will have to have a deeper look over the logs.

[yxonic]

I found that there is a setInterval in awareness that prevents hibernation. I manually cleared it, and the overall billable duration reduced drastically. I tested this with slate, and the awareness update seems not affected without setInterval.

class CustomYDurableObjects<T extends Env> extends YDurableObjects<T> {
  constructor(state: DurableObjectState, env: Bindings) {
    super(state, env);
    clearInterval(this.doc.awareness._checkInterval);
  }
}

[naporin0624]

@yxonic

That's a great discovery!
Would it be possible for you to create a PR?

[yxonic]

@naporin0624 A slight issue is that the DO reports Client disconnected error more often. I'm not sure if this fits a PR or just let people extend a custom DO is fine (like maybe put the snippet in docs?)

[naporin0624]

@yxonic Sorry for the late reply.
Adding a Cost Down Tips section to the README and including
a snippet for a custom DO along with some notes might be the best approach.