JI was already able to update the existing configs. Thank you.
ACurrently our top priority and will be our next big feature released. See hyperdriveWhile waiting for Cloudflare Tunnel for a bit more discussion.
AWill this adress the issue of Hyperdrive placement in APAC region?
AThat's a separate track of work and is coming along soon. That's not a feature it's a fix, sorry for the confusion there.
AThough, that raises a good point. If your setup is in APAC and you're having latency issues, please message me directly.
P@AJR have your team done performance work with Hyperdrive under the hood in the past two weeks?
P
PI'm in the US east again and this is my latency now
P2x improvement
Psame location
Poop, sorry, here are the correct numbers
Pso from 620-770ms to 360-520
P(still not as fast as a VPN to europe but incredible improvement in such a short time!)
PYeah
PUS East → hetzner germany
Pah, I was so excited... well i'm still excited but
PI was about to be like "wow wtf did you change to save 200ms"
Plmk if I can beta test it in the future, sounds very exciting to me
JHi! In which regions/colos can Hyperdrive spawn? And is there any way to know in which location i'm currently connected?
THi João! Hyperdrive can spawn in various regions, usually one that's closest to your Worker making the request, and no, there's no way to know which region it's spawned in
I^ to add to this, Hyperdrive is always spawned in a region with a DO but may not spawn in every DO region (I'm uncertain, only someone on the Hyperdrive team would know). But you can certainly use the non-DO regions as an indicator of where it does not spawn. Here's a community-sourced tool for exploring DO regions: https://where.durableobjects.live/
Tracking where Durable Objects are created, wherever you are in the world.
JIt seems like sometimes the EU Hyperdrive pool for our DB is going unavailable for a few minutes and then coming back online. Could someone take a look at this? Thanks!
Account ID: 978f7d8fe0d7c314743586a46e505f14
Account ID: 978f7d8fe0d7c314743586a46e505f14
JWhile testing we noticed that having a worker close to London try to connect would result in an error, but in other regions it would run properly
Ehello and good day!
im trying to understand. Every other day HyperDrive fails for me for about 1 hour...
and then comes back.
like right now is failing : error: Failed to acquire a connection from the pool.
and there is nothing i can do because i know its not my side, because i can connect directly to the DB. (Yes, this could be a solution, trying to monitor these error and switch to direct connection)
but i think i should be able to work with hyperdrive.
im trying to understand. Every other day HyperDrive fails for me for about 1 hour...
and then comes back.
like right now is failing : error: Failed to acquire a connection from the pool.
and there is nothing i can do because i know its not my side, because i can connect directly to the DB. (Yes, this could be a solution, trying to monitor these error and switch to direct connection)
but i think i should be able to work with hyperdrive.
Eis anyone else experiencing this?
Ei dont even do that many things.... but was hoping to do in the future...
Ethere is the timeouts....
Eand connections not overwhelmed or anything...
EJust wondering if anyone is experiencing this and if there is anyway to solve this.
I think what ill do for the time being is to also put direct connections to the DB and figure out how to failover during these hours.
on the pg side of things:
2024-07-31 10:38:16.201 UTC [569089] [unknown]@[unknown] LOG: invalid length of startup packet
2024-07-31 10:20:26.462 UTC [568369] postgres@db LOG: could not receive data from client: Connection timed out
2024-07-31 10:20:26.462 UTC [568369] postgres@db LOG: unexpected EOF on client connection with an open transaction
I think what ill do for the time being is to also put direct connections to the DB and figure out how to failover during these hours.
on the pg side of things:
2024-07-31 10:38:16.201 UTC [569089] [unknown]@[unknown] LOG: invalid length of startup packet
2024-07-31 10:20:26.462 UTC [568369] postgres@db LOG: could not receive data from client: Connection timed out
2024-07-31 10:20:26.462 UTC [568369] postgres@db LOG: unexpected EOF on client connection with an open transaction
Pthis is EU client → US host, I'm going US client → EU host. Maybe I should run formal query benchmarks but anecdotally yes, my latency is anywhere between 320-590 or so on a warm conn
PI've decided to delay my db performance testing on AWS until we're closer to launch
Pno point in paying 3x more for the same resources until then :)
Pthe plus side is our read queries are now quite optimized, and a replication story could be good for that as well
Pthe writes are... harder
Pwe might do pg functions or something
MIn my environment, Hyperdrive is 10x slower than direct connection, while latencies that are displayed Cloudflare web dashboard are not such bad(~100ms).
The database region is Tokyo(Japan) and I accessed my Workers from Tokyo too.
Does anyone experience a similar problem?
The database region is Tokyo(Japan) and I accessed my Workers from Tokyo too.
Does anyone experience a similar problem?
DDoes Hyperdrive supports Xata with direct postgres connection? Supabase works fine for me but xata do not work. Show /inactive on dashboard.
AInteresting! I hadn't heard of Xata. We've tested across many providers, but that one may be doing something different enough that there's an issue. I'll ask around the team, and take a look when I have some spare cycles if none of them are familiar with it.
MDoes the Xata database have Postgres enabled? “Inactive” means we haven’t seen any recent queries - when you say “doesn’t work” do you mean you can’t query it from your Worker?
DThe hyperdrive stabilished but a simple query run forever with no return. Using pgcli or psql I can connect and run the same query.
DUsing postgres.js direct I can connect but with Hyperdrive, no way.
