> therefore the two separate DO instances have less resources than if they ran on different machines in the same POP Correct, they compete for the same 128mb of ram when they are sharing. Note just because they are eligible for sharing does not mean they will share - often they don't. Btw, bundled cpu limits are not shared, they should be properly accounted for each object in the isolate. https://discord.com/channels/595317990191398933/773219443911819284/869594006445768784

Objects from different namespaces can be placed in the same isolate, if they are implemented by the same script. Basically we allocate one isolate per script per machine, and whatever work arrives on that machine that needs to use that script runs in that isolate.

awesome, good to know - so if we see multiple isolates running the same script within a colo, that means they are running on different machines? What determines that?

Technically we do sometimes create multiple isolates of the same script on the same machine, but only when CPU pressure is high (too much traffic for one thread), not currently when memory pressure is high.

that could change

currently we run work on whatever machine it randomly lands on, we don't make any effort to redirect to a particular machine -- except that of course once a Durable Object is started, all subsequent requests have to go to the same machine.

ok, but just for my mental model - a script never runs on more than one machine in a colo?

sure it does, it can run on all the machine in the colo

any machine that receives an HTTP request for the script will start the script. 🙂

also, I've never seen an entry-point worker run in the same isolate as a DO worker defined in the same script, are those always kept separate?

nope, they could totally be the same isolate.

ah ok, so if 20 parallel requests come in for 20 different objects in the same colo (let's say cold start), how do you determine if that's one machine or 20 machines? Does that take worker run data into account? or just like a generic loadbalancer

Historically, we'd just run the objects on whatever machine happened to receive the connection requesting them, which was fairly random (but if the same caller requested multiple objects then they'd end up on the same destination machine). I think @User recently added some randomization, so now we'll choose a random machine for each object. In the future we'd like to do something fancy and adaptive but this gets the job done for now.

ah makes sense, looking forward to that randomization change, I think maybe next week? Gotta run to dinner, but one last question: when objects are evicted, I'm assuming all objects in the isolate are evicted, and then they have no future affinity to that machine, right? i.e they can be recreated in possibly other machines in that colo

No, individual objects are evicted at different times, it's not the whole isolate. I am not sure if they retain affinity to the machine, or if so, for how long.

@User is this intentional? I dont see it mentioned in the docs or in other issues: https://github.com/mrbbot/miniflare/issues/31

I have replied on the Github issue, but I can't seem to reproduce your issue? Would be great to have some more info

apologies, user error 🙂

No worries.. happens all the time 🙂 Not to me ofc.. no no no.. but I hear it happens to other people all the time 😄

hahah 😛

God.. if people only knew how many dumb mistakes like that I have made over the past 25-ish years 😄 But.. more importantly.. You have a DO name of UserAggregate. Do you mean Aggregate like the DDD type Aggregate? Because if that is the case, I would love to have a chat with you, because I think that will become a very important pattern to build on top of Durable Objects..

Correct, yes im building an event-sourcing based solution on top of DurableObjects for https://blog.cloudflare.com/developer-summer-challenge/ and its going really well I think its going to work well

Absolutely love it. Please keep me in the loop on how it is going. This is such a cool space indeed. Would love to see the final submission!

yep I will indeed, I think its the "killer app" for DurableObjects and serverless event-sourcing

I have build server less event sourcing solutions before (when I worked at https://www.getbamboo.io/) and it was a headache to say the least. I think DurableObjects solves many of those issues

But ye will let you know once im a bit further along

Yeah.. I have built one at Linc too. And I agree, it has the potential to solve so many of those headaches. But it is going to be a bunch of learning around patterns and platform support etc.

Oh, I'll try that! I actually though HTTP/2 was terminated at the edge and everything afterwards was HTTP/1.1.

Yes, but it is terminated in the machine that you end up on. And that one machines re-uses the same worker isolate to process any requests for that same worker script.

Alright, that makes sense 🙂 Does the CF-RAY response header refer to a single TCP connection to a single machine? Is that why it is the same for multiple requests over a HTTP/2 connection?