#Any way to not use metal?

28 messages · Page 1 of 1 (latest)

nova barn
#

Is there any way to not use metal for my deployment? its leading to huge slowdowns and has broken my app in production. I need to resolve this asap. is there any way at all to go back to US Oregon?

teal pythonBOT
#

Project ID: 019d11e1-619b-49aa-9f60-379506b03485

nova barn
#

019d11e1-619b-49aa-9f60-379506b03485

cerulean arrow
#

hobby users now deploy exclusively to metal, we have found any slowdowns can be attributed to using the public network to connect to the database or inefficient code paths.

nova barn
#

Theres only a flask API in my project. my DB is a supabase instance

#

my app just has one endpoint which generates an embedding and calls a supabase RPC function. was ~6-8s response times before which im fine with but thats jumped to me having to increase my RAM/CPU limits as well as 25s response times now

cerulean arrow
#

what region is your supabase database in

nova barn
#

West US (north california)

cerulean arrow
#

what region is your app deployed into?

nova barn
cerulean arrow
#

then you have them both in the same zone

nova barn
#

yeah so if anything metal should be faster than orgeon

cerulean arrow
#

yep it has newer CPUs

nova barn
#

yeah so im not understanding how my RAM/CPU usage almost increase by 2x and my response times 3x

#

i was running 4gb ram and 4vcpu before and it was all fine but after metal i get out of memory issues. after increasing both to 8/8 my vcpu usage is 7 during the request

cerulean arrow
#

perhaps the new CPUs don't perform well for your specific task?

nova barn
#

yeah it just sucks because now ill most likely have to switch over to a new cloud provider. huge fan of railway but i figured we wouldve had some email warning or something instead of just waking up monday to find out my app was broken all weekend and also that there is nothing i can do about it except pay more money to go back to the old server

cerulean arrow
#

paying more money wouldn't help long term, pro users will eventually be moved to metal too, the end goal being for Railway to leave GCP.

sorry that this didn't work out for you!

nova barn
#

some interesting customer support. theres numerous people complaining so clearly theres some underlying issues. all this without warning too. lol

cerulean arrow
#

I'm really not sure what we can do about this unfortunately, we have actively been working on moving off of GCP

coral parcel
#

i am having the same issue, my postgres db on railway can only be set in oregon, but my app deployment ar restricted to metal which are in the west causing huge slowdowns and connection timeouts

hollow harnessBOT
#

New reply sent from Help Station thread:

We also have found slower requests with services running on metal and db’s not running on metal. Also, how and why was this forceful deployment not communicated?

You're seeing this because this thread has been automatically linked to the Help Station thread.

hasty monolith
#

I'm also seeing a noticeable slowdown (increase of +- 100ms per request on the private network)

If the aim is to move entirely off GCP, is there a timeline of when services with volumes will be moved across as well?

hollow harnessBOT
#

New reply sent from Help Station thread:

I'm also seeing a noticeable slowdown!it’s not possible to change the region, then why do you offer other options? Why mislead users who genuinely appreciate your service and are paying for it? This feels unfair to those of us who rely on Railway for our projects and want the best experience possible.

You're seeing this because this thread has been automatically linked to the Help Station thread.

cerulean arrow
#

The slowdowns are generally caused by using the public network to communicate with the database.

coral parcel
#

I am using the private network and everything was perfect before switching to metal