1Yeah I'm in quiet season at work so I finally have time to dedicate to re-architecting everything
Li believe so
LThere isn't an ETA yet, so if you need it now, I suggest doing the migration of the data yourself for now.
1No worries appreciate the clarity. I'll use it as an opportunity to rewrite everything while I'm at it, there's been plenty of changes I can take advantage of since I first built it all
LI probably shouldn't have used the word "clock". It's confusing. DOs are billed on wall clock time. However, their run length limits are CPU clock time which is an order of magnitude or two more generous when you have external fetches involved. It wouldn't surprise me if it were able to wait on a fetch for 20 minutes. You'll pay for the DO the whole time, but it would still use less than 30 seconds of CPU.
1If I delete a DO's storage, let it evict then request the same instance, will it always spawn in the same colo? I've gotten an instance in Perth which I'd really love to move closer to home
PIf it's being spawned off of a request, it's usually pretty sticky from my experience, but if you specify a location hint instead I've had more success with it sometimes moving to a different datacenter. Not quite sure what the spawn algorithm is because it's seemingly slightly different each time I try.
For what it's worth, when I want a DO instance near a specific point, this is pretty inefficient but I just have a worker spawn and destroy DO instances with a region hint and with slightly different names then returns the name/id of the one in the POP I want
For what it's worth, when I want a DO instance near a specific point, this is pretty inefficient but I just have a worker spawn and destroy DO instances with a region hint and with slightly different names then returns the name/id of the one in the POP I want
PThis is in ENAM though, so I don't know how it is in other regions
1The 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
PHonestly, 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
1I like it thank you
Pnp 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
PMy old trick was to spin a lambda instance in a nearby AWS center and hit the endpoint...
1Its 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
PThat 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
1So 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
1These instances are also entirely fresh with no data stored beyond the runtime-abstracted stuff
IAs far as I remember, yes.
12025 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