I know there's this in the docs ``` Durable Object alarms are not reset between test runs and do no
I know there's this in the docs
But I believe my afterEach should cover this
But I believe my afterEach should cover this
Durable Object alarms are not reset between test runs and do not respect isolated storage. Ensure you delete or run all alarms with runDurableObjectAlarm() scheduled in each test before finishing the test. afterEach(async () => {
// Clear any pending alarms between tests.
await runInDurableObject(stub, async (_instance, state) => {
await state.storage.deleteAlarm();
});
vi.restoreAllMocks();
});this.state.getWebSockets on each stub, is this 1 DO request per stub? Do these count toward the subrequest limit of the initially invoked Worker?
Will the DO billing charge for cold-starts etc ?No, you pay only the time after your DO is running.
IF, Workers consumes 10ms (and hence billing time = 10ms) for above simple Use-case, is it "FAIRLY ACCURATE" to assume that the DO will also consume 10ms (and hence billing time = 10ms) for the same Use-case.Assuming that the
10ms is actual round trip time for your operation, then yes, DOs should have similar performance as Workers. It's the same runtime so code behavior is identical.@cloudflare/next-on-pages with DO's?durable-utils@0.3.0: https://github.com/lambrospetrou/durable-utils#readmeStaticShardedDO abstraction extended with more methods one/some/all() and tryOne/trySome/tryAll(). There are a couple other utilities added for retries like tryN(...).StaticShardedDO class and let me know what you think or what's not convenient.Conclusion : Workers Compute is 12.5x times COSTLIER than DO-Compute.That's a very unusual conclusion for real world applications. Anyone can do their calculations of course, but please be careful when you compare them otherwise you will be in for not so nice surprises.
walltime is the max of it anyway in the worst case.Q#1 : What is "billable compute" time for Worker ?This is NOT correct. Since your worker was just waiting for the DO here it doesn't count as CPU time and shouldn't be billed.
A#1 : (My Understanding) : Time_END - Time_START - 10ms
Could not serialize object of type "DurableObject"
RpcTarget class will need to proxy function calls to required stub. In your example, BarRpcTarget needs to extend RpcTarget, and its constructor() should add the required stub which was already pulledby the instanced Worker, and also have class methods that will essentially call this.stub.func() on the actual DO stub. Screenshot is an example of my implementation for RpcTarget

adding this global ordering type of logic on a class which extends this classNot sure if extending is the right thing, I usually prefer composition, so another class using the sharding abstraction as its storage layer and for localized queries. The outer class is mostly to orchestrate which shards to query and do potential aggregations if needed.
do you ever see a future possibility of making the # of shards dynamic? AKA scaling storage practically infinitely?Absolutely. It's in my plans, but I want to find a nice API for it first. Dynamic shards need splitting and merging shards over time, so ideally we should provide some DO native hooks for it. Until those are built and published I want to experiment doing it ontop but needs some time.
getRpcTarget() on your DO, and calling it from a Worker allows you to pass around that returned value and anyone calling it will go back to the DO.this.state.getWebSockets10ms@cloudflare/next-on-pagesdurable-utils@0.3.0StaticShardedDOStaticShardedDOone/some/all()tryOne/trySome/tryAll()tryN(...)walltimeCould not serialize object of type "DurableObject"RpcTargetRpcTargetBarRpcTargetthis.stub.func()getRpcTarget()