high runtime fees #13

Activity

1. naporin0624 commented on Mar 30, 2024

   

   naporin0624

   on Mar 30, 2024

   Last edited by naporin0624

   Member

   More actions

   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.
2. naporin0624 commented on Mar 31, 2024

   

   naporin0624

   on Mar 31, 2024

   Member

   More actions

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

   👀React with 👀1Reacted by Junglei Kim
3. naporin0624

   added

   questionFurther information is requestedFurther information is requested

   on Mar 31, 2024
4. CiskaLV commented on Aug 26, 2025

   

   CiskaLV

   on Aug 26, 2025

   More actions

   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.
   
5. naporin0624 commented on Aug 28, 2025

   

   naporin0624

   on Aug 28, 2025

   Member

   More actions

   @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.
6. CiskaLV commented on Aug 28, 2025

   

   CiskaLV

   on Aug 28, 2025

   More actions

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

   👍React with 👍1Reacted by naporitan
7. yxonic commented on Sep 10, 2025

   

   yxonic

   on Sep 10, 2025

   More actions

   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);
     }
   }

   

   👍React with 👍1Reacted by Frank Leng

   🎉React with 🎉2Reacted by Frank Leng and John Chang
8. naporin0624 commented on Sep 10, 2025

   

   naporin0624

   on Sep 10, 2025

   Member

   More actions

   @yxonic

   That's a great discovery!
   Would it be possible for you to create a PR?
9. yxonic commented on Sep 11, 2025

   

   yxonic

   on Sep 11, 2025

   Last edited by yxonic

   More actions

   @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?)
10. naporin0624 commented on Nov 13, 2025

    

    naporin0624

    on Nov 13, 2025

    Member

    More actions

    @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.