b082e796-c15c-43c8-b3d6-81fc47342308

Are you connected to the database under the private network?

yes I am

of course

that was the whole point

bringing the DB inside the web app's project and connecting via the private network

MYSQLDATABASE="${{MySQL.MYSQLDATABASE}}"
MYSQLHOST="${{MySQL.MYSQLHOST}}"
MYSQLPASSWORD="${{MySQL.MYSQLPASSWORD}}"
MYSQLPORT="${{MySQL.MYSQLPORT}}"

and that's the Python code:

DATABASE_CONFIG = {
'user': 'root',
'password': os.environ.get('MYSQLPASSWORD'),
'host': os.environ.get('MYSQLHOST'),
'port': os.environ.get('MYSQLPORT'),
'database': os.environ.get('MYSQLDATABASE')
}

def getdb(): if hasattr(g, 'dbconn') and g.dbconn.isconnected():
return g.dbconn else: g.dbconn = mysql.connector.connect(**DATABASECONFIG) return g.dbconn

it used to be almost instant even when I was connecting from one project to another (via the public access)

so it's crazy that now that both the web app and the DB are in the same project, queries are slower

the only difference I can see is that the legacy DB was mysql:8 and the new one is mysql:9

(the legacy DB was started in Sept 2023, the new one today)

it's definitely not a code issue since, again, it worked just fine in the previous configuration earlier today

At the moment the app is using mysql-connector-python==8.0.33

that is interesting, I don't really see why that would be the case

Well, one way or another, it's the case 🙂

any help would be appreciated

yea I don't have the faintest idea why it could be slow for you, I've never seen anyone report a slow private network connection either
I did mention this post to the team though but they're currently out of office for the holidays

ooh good catch, thank you

yea I did some more digging and it a lot of people are reporting that their services have been moved to metal, metal doesn't support volumes yet so databases wouldn't be moved, causing the service and database to be in different regions which can cause delay even on private network

Can you check the top of the build logs for your service, it'll mention the region here, let me know what it says

web app: [Region: us-west1]

database

So it is the same region then, unless the UI is correct and the builder is reporting the region incorrectly 🤔

So from what I can see in the UI for the web app I have

and for the DB the one above

I found out that hobby deploys are exclusively metal now, which leads me to believe that the builder is incorrectly reporting the region
but then the difference in region would explain the delay, although the delay should still be somewhat minimal

so the web app would be in US West California USA and the DB in US West Oregon USA?

exactly

and I can't switch back the web app to West Oregon USA?

Or would switching to Pro give more control?

Switching to pro would give you more control yes, under the pro plan you'll be able to switch the web app back to oregon

it kind of defeats the purpose that 2 services under the same project are now in 2 different regions

All of this after spending 2 hours migrating my DB to the same project as the web app to benefit from private networking

and they're not in the same region…

very true, I'm not sure why Railway didn't just wait until they had volume support under metal before forcing metal deploys 🤔

don't worry though, volume support should be coming soon and then everything will be in the exact same region once again

but now I'm stuck

it's either upgrade to Pro or wait

@Fragly am also facing the same challenges for me all my deployment were failing until I changed to v2 after that my app is very slow and getting 504 gateway time out any help

in our testing the difference in regions add a +20 ms time to the database queries, that should not be perceived in the end user application unless you are making many databases queries per API route.

if that kind of additional time matters, it's unlikely to be fit for the hobby plan regardless of regions.

you may upgrade to pro or optimize your queries you make.

For a single database query?

Does the Pro plan improve connection speeds? (or query execution speed).

no, the slow down you are experiencing is not a platform limitation

How do you explain it occurred after the migration of the DB to the same project as the web app?
It was working perfectly fine before.
The only rational explanation seems to be the different regions.

The zone itself is not causing the issues, instead it's exposing and exacerbating existing inefficiencies or issues in your code; meaning the zone difference is more like a trigger for revealing these issues in your application

But why did it work fine before? That's the question.

your app and database where in the same zone, and now the tiny bit of extra latency has exacerbated massive inefficiencies in your codebase

there's nothing from the platform side of things we can do about this

except having both the web app and db in the same region again.
How can I do this?

they are still in the same region, just different zones

well, in the same zone then, sorry for my semantic error

how can I have them in the same zone?

Can you set both in the same ZONE if you're on the Pro Plan?

yes

and pricing wise, it just means that I have to add $15 per month as a "basis" + usage (as for the Hobby plan, for which the basic excl. usage is $5). Correct?

$20 plus whatever your resources cost

@Brody My web app and database are in the same region as us west Oregon USA but am having operation time out after 30001 milliseconds with 0 byte received on railway app during database queries

That would be an issue with your application that we are not able to provide support for

@Brody if I upgrade to a pro plan with the database and web app in the same region will it enhance my queries.. for the records I have checked my application completely.. and the issue is not from my end.

Up until yesterday everything was working perfectly well until I changed my runtime to v2 after my deployment we constantly failing

There's definitely a recurring correlation between the fact we had to switch to V2 and performance issues.
It must be at least acknowledged by Railway, as a minimum.

I think railway must be proactive to say the least and provide a definite solution because am getting frustrated here.

yes we are aware but due to the fact that this is not caused by any platform issues there's nothing we can do about this, sorry

Ok, let's recap:
The issue has been experienced by many users due to a (forced) change in their runtime configuration, enacted by Railway (probably for some good reasons).
Everything was running smoothly for those users (incl. myself) before this forced switch.
Railway considers they have no responsibility in the degradation of the service which was triggered by this configuration change, which has just revealed the poor coding skills of those users.

Not very rational IMO.

And I would add: the only "solution" seems to be to pay $15 more per month to at least make sure the web app and the DB are in the same zone.
Well, well, well…

I mean, I love Railway, don't get me wrong.
But this doesn't sound quite right.

we have only seen a handful of reports about slow downs, most of them solved by using the private network, given that 100% of hobby users are now on metal, so I would say it has not been experienced by many users

there's always a difference between those who complain and those who don't because they can't articulate their complaints.
But for those who did, there's a causal relationship, it's undeniable.

anyways, spending time writing those lines is better invested upgrading to Pro I presume.

@Brody I'm pretty happy that I spent time optimizing my main queries.

Thanks for pushing me in the right direction.

My performance is now MUCH BETTER than it used to be before my switch to V2.
I have implemented connection pooling for mysql and joins on my complex queries.
Top result.

Still considering upgrading to Pro to have both services in the same zone.

I could not be more happy to hear that, I'm really sorry if I came off as pushy, but this is truly some awesome news

If anyone is developing Flask web apps and needs some assistance on the optimization front, I'm happy to share my takeaways. Cheers

gave you some credits for your time!

when metal supports volume you can move the db to the same zone to get that -10 ms back for the query time

Thank you so much!

I guess this will be announced in the weekly newsletter when available.

yep 100%

as fred as shown above he was able to significantly speed up his db queries by writing more efficient queries.

but 800-900ms makes me think you are still using the public network one way or another.

!s