The locations I wanna use are within the same location hint, the routing just seems to really suck i

The locations I wanna use are within the same location hint, the routing just seems to really suck in this case (going from side of Australia to the other can be awful in terms of routing). I also don't really wanna have to stray away from the current name I am using for this instance

11984 Ford Laser The locations I wanna use are within the same location hint, the routing just se...

PhoenixSpace•10/21/25, 1:02 AM

Honestly, I'd just spin a quick test worker to spin and destroy a DO like 10 times with the same name with a set location hint. YMMV but usually thats enough to get a couple of different POPs. If that works, then just do that again with the DO class and name you want until it's in the right region then use it

PPhoenixSpace Honestly, I'd just spin a quick test worker to spin and destroy a DO like 10 tim...

1984 Ford LaserOP•10/21/25, 1:03 AM

I like it thank you

PhoenixSpace•10/21/25, 1:03 AM

np and please let me know how it goes. I haven't experimented with coercing DOs to specific POPs outside of ENAM/WNAM and would love to know if that hack works elsewhere lol

PhoenixSpace•10/21/25, 1:04 AM

My old trick was to spin a lambda instance in a nearby AWS center and hit the endpoint...

PPhoenixSpace np and please let me know how it goes. I haven't experimented with coercing DOs ...

1984 Ford LaserOP•10/21/25, 1:05 AM

Its never been a problem before, normally get them always in Melbourne which is close to home. There's only a 33% chance a DO will spawn in Perth via Melb instead of Sydney so I just got unlucky with this one. I will test out hitting the same instance and see how I go

11984 Ford Laser Its never been a problem before, normally get them always in Melbourne which is ...

PhoenixSpace•10/21/25, 1:07 AM

That makes sense. I'm working on a small tool that I'll need to put small DOs in very specific areas (one of which is in Australia) so I've been playing around more and more with forcing the DO placement algo where I want lol. I kinda wish CF could just let me specify the IATA code of where I want it, but I'm guessing there are architecture limitations there

1984 Ford LaserOP•10/21/25, 1:09 AM

So to confuse myself more, I just requested a new instance (first one was named '2025', this one is '2026') and it ended up in the same colo but with far better response times when hot?? Def need to test this out more

1984 Ford LaserOP•10/21/25, 1:09 AM

These instances are also entirely fresh with no data stored beyond the runtime-abstracted stuff

11984 Ford Laser If I delete a DO's storage, let it evict then request the same instance, will it...

Isaac McFadyen•10/21/25, 1:10 AM

As far as I remember, yes.

1984 Ford LaserOP•10/21/25, 1:10 AM

2025 gives me around 350ms when hot, 2026 gives me around 150ms which is not insignificant. Both in Perth

PhoenixSpace•10/21/25, 1:10 AM

How are you measuring the colo it's running in?

1984 Ford LaserOP•10/21/25, 1:10 AM

Just from the CF logs

Isaac McFadyen•10/21/25, 1:10 AM

In fact if I remember correctly once you create a DO with a specific name it's always in that colo even if you delete, evict, and recreate a while later (not 100% but that's what I remember).

PhoenixSpace•10/21/25, 1:11 AM

Interesting

PhoenixSpace•10/21/25, 1:11 AM

That's also pretty annoying

PhoenixSpace•10/21/25, 1:11 AM

My habit of completely not caring about my DO names and making them random numbers or UUIDs comes in handy once again!

1984 Ford LaserOP•10/21/25, 1:12 AM

Its just annoying cos I have a bunch of data that I want to associate to a specific year, I can rearchitect around it but would rather not

PPhoenixSpace My habit of completely not caring about my DO names and making them random numbe...

Isaac McFadyen•10/21/25, 1:12 AM

If you do this I highly recommend using newUniqueId() rather than idFromName() if you can, it saves a round trip

11984 Ford Laser 2025 gives me around 350ms when hot, 2026 gives me around 150ms which is not ins...

PhoenixSpace•10/21/25, 1:12 AM

I've had this happen before, and I genuinely have no idea what causes it. Maybe different machines or something? But also usually for me when it happens, sometimes when its recreated out of idle later the latency changes again

1984 Ford LaserOP•10/21/25, 1:12 AM

I'll wait a bit and see if I get similar results

IIsaac McFadyen If you do this I highly recommend using newUniqueId() rather than idFromName() i...

PhoenixSpace•10/21/25, 1:12 AM

Oh interesting, I didn't know that. Thanks for the tip!

PhoenixSpace•10/21/25, 1:13 AM

rn my scheme is usually [IATA of incoming request worker]-[DO type/name]-[some sort of short random number or UUID] so that in logs it shows up a little nicely, but I think I'm just going to go full IDs now

Isaac McFadyen•10/21/25, 1:14 AM

Yeah basically if you use the

idFromName

idFromName

the runtime has to check (globally) whether the DO exists already whereas if you do

newUniqueId

newUniqueId

it's generated in a way that it will always be unique and doesn't need to do that double-check

PhoenixSpace•10/21/25, 1:14 AM

Oh that makes... a lot of sense. The more you know

PPhoenixSpace Oh that makes... a lot of sense. The more you know

1984 Ford LaserOP•10/21/25, 1:15 AM

There's a note about it here for reference: https://developers.cloudflare.com/durable-objects/api/namespace/#newuniqueid

PhoenixSpace•10/21/25, 1:16 AM

Ah, I never used newUniqueId so I guess I missed that. Thanks for the link!

PhoenixSpace•10/21/25, 1:21 AM

Looking over the docs again, I am actually kind of curious why there isn't a way to spawn a DO at a specific location or minimal latency to a specific CF POP. I wonder if it's a engineering limitation or just lack of demand (I'm guessing I will probably never get a specific answer)

PPhoenixSpace Looking over the docs again, I am actually kind of curious why there isn't a way...

1984 Ford LaserOP•10/21/25, 1:24 AM

Probably just to stop people absolutely spamming new instances in 1 pop

PhoenixSpace•10/21/25, 1:26 AM

lmao

PhoenixSpace•10/21/25, 1:26 AM

yeah fair enough

PhoenixSpace•10/21/25, 1:27 AM

back to spinning up lambda instances to pre-emptively create DOs :)

1984 Ford LaserOP•10/21/25, 1:28 AM

I'm actually wondering if this is related to my ISP in some way, I'm getting directed to Perth on other Workers not at all related to DOs

PhoenixSpace•10/21/25, 1:28 AM

It very well could be. Maybe your ISP is peered with an interchange in perth?

PhoenixSpace•10/21/25, 1:28 AM

Easy solution is to check https://workers.cloudflare.com/cdn-cgi/trace :P

1984 Ford LaserOP•10/21/25, 1:30 AM

I just got Adelaide which is different again :NotLikeThis:

PhoenixSpace•10/21/25, 1:30 AM

That's so weird

PhoenixSpace•10/21/25, 1:30 AM

For what it's worth, my ISP sends my requests to a datacenter ~400 miles away from me, ISPs are just weird

PhoenixSpace•10/21/25, 1:31 AM

ime it's just luck whether or not your ISP is sane with routing

1984 Ford LaserOP•10/21/25, 1:31 AM

Melb to Perth is like ~3000km hahaha

1984 Ford LaserOP•10/21/25, 1:31 AM

That would be insane routing if so

PhoenixSpace•10/21/25, 1:31 AM

I think cloudflare only has a handful of POPs in Australia though

1984 Ford LaserOP•10/21/25, 1:32 AM

Melb, Syd, Bris, Adel, Per

1984 Ford LaserOP•10/21/25, 1:32 AM

Oh and tas

PhoenixSpace•10/21/25, 1:32 AM

so wherever it's popping out, the closest POPs may be either Adelaide or Perth

1984 Ford LaserOP•10/21/25, 1:32 AM

Melb to perth is basicallty bas bad as it gets

PhoenixSpace•10/21/25, 1:32 AM

lmao

PhoenixSpace•10/21/25, 1:32 AM

huh

PhoenixSpace•10/21/25, 1:32 AM

according to that Perth doesn't host DOs

PhoenixSpace•10/21/25, 1:32 AM

that's strange

1984 Ford LaserOP•10/21/25, 1:33 AM

Yeah the DO is in Mel but request being routed through Perth