What? They don't restart 280+ instances because each DO instance is only located in 1 colo at a time

What? They don't restart 280+ instances because each DO instance is only located in 1 colo at a time. You severely misunderstand the platform

11984 Ford Laser What? They don't restart 280+ instances because each DO instance is only located...

Super Morris•2/27/25, 9:05 PM

while testing yesterday we requested a worker from different locations subsequently and there where cold start times of 1+ seconds from each location. might have been bad timing... today we saw that it only needs to cold start once for each DO instance globally, however about 30seconds later the same thing... so still 1 second of wait for each DO that is idle for more than 30 seconds... thats just stupid for our use-case.
we will use neon + hyperdrive for now.... 15-30 ms read and write. both from us and eu (for a eu hosted db)... no cold starts

SSuper Morris while testing yesterday we requested a worker from different locations subsequen...

1984 Ford LaserOP•2/27/25, 9:12 PM

Sounds like you are better suited to a single DB versus lots of smaller DBs via DO, not every backend architecture will be suitable for DOs

Iggy•2/27/25, 9:43 PM

I have a very basic worker + sqlite backed DO that is reading 10 rows. I'm getting ~150ms in round trip time from it (the SQL duration is <1ms), and coworkers across the country are getting >=600ms consistently, even when hitting local data centers. Shouldn't they all be roughly the same time? What's causing the huge discrepancy?

IIggy I have a very basic worker + sqlite backed DO that is reading 10 rows. I'm getti...

1984 Ford LaserOP•2/27/25, 9:47 PM

Are your coworkers hitting the same DO instance as you? Instances exist only in 1 colo so maybe they are seeing an unfavourable route to the instance, maybe get them to request a new instance, provide a location hint, and see if they get faster times

Iggy•2/27/25, 9:48 PM

We're both executing the exact same curl if that's what you're asking?

1984 Ford LaserOP•2/27/25, 9:48 PM

I mean when you do idFromName()idFromName() are you both requsting the same name?

Iggy•2/27/25, 9:48 PM

Yeah

1984 Ford LaserOP•2/27/25, 9:49 PM

Get them to try a new unique ID and see if they still get the same timea after multiple requests. First request to new DO will be kinda slow, but should be faster aferwards

Iggy•2/27/25, 9:50 PM

Hrm maybe I'm misunderstanding, but if I have data peristently stored in sql for that given name, isn't it going to be gone if I use a new name?

1984 Ford LaserOP•2/27/25, 9:51 PM

oh yes of course lol I am just thinking that your coworkers are further away from the instance, or their ISP is taking longer to route the request

Iggy•2/27/25, 9:51 PM

I definitely think I'm confused lol

Iggy•2/27/25, 9:51 PM

Durable Objects do not currently change locations after they are created1. By default, a Durable Object is instantiated in a data center close to where the initial get() request is made. This may not be in the same data center that the get() request is made from, but in most cases, it will be in close proximity.

if I do the initial request in ATL, does that mean somebody in SEA is actually going to ATL?

1984 Ford LaserOP•2/27/25, 9:52 PM

yes

Iggy•2/27/25, 9:52 PM

their cf-ray is -SEA but it sounds like it's an internal hop from SEA to ATL?

Iggy•2/27/25, 9:52 PM

am I totally using DOs incorrectly then?

Iggy•2/27/25, 9:53 PM

my goal is to have isolated SQLite databases per idFromName(foo)idFromName(foo), but low latency based on user location*

1984 Ford LaserOP•2/27/25, 9:53 PM

You would need to create each user's instance with a location hint the first time its requested

Iggy•2/27/25, 9:53 PM

IOW if I have multiple geolocations hitting the same

id

id

, it's not actually running closest to each of them, it's running closest to the first requestor?

1984 Ford LaserOP•2/27/25, 9:54 PM

yes, probably

1984 Ford LaserOP•2/27/25, 9:54 PM

obvs no guarantees of anything lol

Iggy•2/27/25, 9:54 PM

ah man ok

Iggy•2/27/25, 9:54 PM

that... kinda changes everything. I was under the impression they were all executing closest to the user

1984 Ford LaserOP•2/27/25, 9:54 PM

A Worker does, DOs not necessarily

Iggy•2/27/25, 9:55 PM

but does that matter if my worker is just a proxy to a DO?

1984 Ford LaserOP•2/27/25, 9:55 PM

Can any orange names provide any timelines on being able to re-locate DO instances?

Iggy•2/27/25, 9:55 PM

I have an EA I can ask if it's secret

Iggy•2/27/25, 9:56 PM

i'm trying to create shared state across many geolocations and it sounds like that's not possible right now

1984 Ford LaserOP•2/27/25, 9:56 PM

For shared state you would wanna use a single instance, or persist state across multiple instances which is not the easiest to manage

1984 Ford LaserOP•2/27/25, 9:56 PM

D1 with upcoming replication might be the eventual solution for you

Iggy•2/27/25, 9:57 PM

good thing all of our servers are in one single location lol

Iggy•2/27/25, 9:57 PM

well, mostly.

1984 Ford LaserOP•2/27/25, 9:58 PM

I wonder if your coworkers get the same wall times if they simply pull a stub from the worker and the DO does something simple like print to console. This would help determine if its related to routing or something else DB related

Iggy•2/27/25, 10:00 PM

yeah i'm going to try that real quick

Iggy•2/27/25, 10:01 PM

that means I wont get the benefit of the data replication though

Iggy•2/27/25, 10:04 PM

what's the goal for dynamic relocation?

IIggy that means I wont get the benefit of the data replication though 😅

1984 Ford LaserOP•2/27/25, 10:08 PM

What data replication? DOs aren't replicated

Iggy•2/27/25, 10:09 PM

yeah i think i just really misunderstood

Iggy•2/27/25, 10:09 PM

I was under the assumption that DOs were always executed closest to the user, and sqlite-backed ones have shared data across all of them

1984 Ford LaserOP•2/27/25, 10:10 PM

Nah every instance is entirely unique to one another. Geolocation isn't a good way to split DOs, doing it per user or account or something is the way to go

Iggy•2/27/25, 10:11 PM

tl;dr is that i'm trying to build globally distributed ssr, where ssr data resolution is sqlite backed

Iggy•2/27/25, 10:11 PM

but it sounds like that's not what i'm going to get here?

1984 Ford LaserOP•2/27/25, 10:12 PM

Nah you will, every user will request their own DO instance versus 1 per geoloc or whatever

Iggy•2/27/25, 10:12 PM

but "their own DO instance" needs to have sql data already written to it no?

1984 Ford LaserOP•2/27/25, 10:12 PM

Like for me, my backend is related to sports matches, so I have a DO instance per sports match

Iggy•2/27/25, 10:12 PM

i think that's my gap

1984 Ford LaserOP•2/27/25, 10:13 PM

Well yes which you would do upon instantiation, or setup a SQL migrations system

Iggy•2/27/25, 10:13 PM

but wont the instantiation mean it so the DO is closest to me/the server setting it up?

1984 Ford LaserOP•2/27/25, 10:13 PM

No because it wont be requested until the user needs it

1984 Ford LaserOP•2/27/25, 10:14 PM

The constructor isn't called until the DO is requested, which would first be done when a user creates their account

1984 Ford LaserOP•2/27/25, 10:14 PM

What info does a user need before their account exists?

What? They don't restart 280+ instances because each DO instance is only located in 1 colo at a time

Similar Threads

Similar Threads

Similar Threads