2025 gives me around 350ms when hot, 2026 gives me around 150ms which is not insignificant. Both in
2025 gives me around 350ms when hot, 2026 gives me around 150ms which is not insignificant. Both in Perth
PHow are you measuring the colo it's running in?
1Just from the CF logs
IIn 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).
PInteresting
PThat's also pretty annoying
PMy habit of completely not caring about my DO names and making them random numbers or UUIDs comes in handy once again!
1Its 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
IIf you do this I highly recommend using newUniqueId() rather than idFromName() if you can, it saves a round trip
PI'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
1I'll wait a bit and see if I get similar results
POh interesting, I didn't know that. Thanks for the tip!
Prn 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
IYeah basically if you use the
idFromName the runtime has to check (globally) whether the DO exists already whereas if you do newUniqueId it's generated in a way that it will always be unique and doesn't need to do that double-checkPOh that makes... a lot of sense. The more you know
1There's a note about it here for reference: https://developers.cloudflare.com/durable-objects/api/namespace/#newuniqueid
PAh, I never used newUniqueId so I guess I missed that. Thanks for the link!
PLooking 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)
1Probably just to stop people absolutely spamming new instances in 1 pop
Plmao
Pyeah fair enough
Pback to spinning up lambda instances to pre-emptively create DOs :)
1I'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
PIt very well could be. Maybe your ISP is peered with an interchange in perth?
P1I just got Adelaide which is different again :NotLikeThis:
PThat's so weird
PFor what it's worth, my ISP sends my requests to a datacenter ~400 miles away from me, ISPs are just weird
Pime it's just luck whether or not your ISP is sane with routing
1Melb to Perth is like ~3000km hahaha
1That would be insane routing if so
PI think cloudflare only has a handful of POPs in Australia though
1Melb, Syd, Bris, Adel, Per
1Oh and tas
Pso wherever it's popping out, the closest POPs may be either Adelaide or Perth
1Melb to perth is basicallty bas bad as it gets
Plmao
Phuh
Paccording to that Perth doesn't host DOs
Pthat's strange
1Yeah the DO is in Mel but request being routed through Perth
1Which is even weirder
Phuh.
1
1PIt's just taking the scenic route
P:)
Pdata is going for a little trip
1Should be only a 25% chance a Melb DO goes via Perth
PCould always be load balancing too, who knows what traffic looks like
1I switched to my phone hotspot and get Melb on the cdn-cgi trace but the Worker calls still being routed through Perth. I think I'd better ignore this or it'll send me crazy