Mind sharing your build logs?

https://bookmarklets.up.railway.app/log-downloader/

Thanks for replaying, here the logs:

Run:

Dec 23 08:07:03

docker run -it us-west1.registry.rlwy.net/b3606e15-9ed1-43d5-94c5-b391086149bc:5bcd6f63-c312-4b01-88ae-da724beccee5

Dec 23 08:07:03

Dec 23 08:07:03

Build time: 68.70 seconds

Dec 23 08:07:05

Dec 23 08:07:05

The selected runtime: LEGACY is not supported in this region: us-west2.

Dec 23 08:07:05

You can update the runtime in your service settings

That works, you just need to go to your service's settings and set runtime to v2 - you're currently on a legacy runtime which isn't supported anymore

I see. Could you provide more information about Legacy and V2 things? Sorry, I am very new here.

Its works, thanks a lot!

If you have any information about the changes from Legacy to V2, especially how this could affect my webapp, I will really appreciate.

Once again, thank you very much.

No worries, I'd be happy to explain

Railway's original runtime had some issues, biggest of which stemmed from networking issues like private networking initialization times. It was also pretty limited. Railway's solution was to create runtime v2 which serves as an update to the original - now legacy - runtime. This runtime has better private networking initialization times, performance boosts and magic port discovery (among other benefits)

The reason you're now seeing this error is because Railway recently made the change to have hobby deploys run on metal (Railway's own datacenters) rather than third party datacenters. Railway's new datacenters don't support the legacy runtime and so you're now receiving that error, by switching to v2 runtime you're ensuring your deployments can run properly on Railway's servers

You can get a lot more information on Railway's runtimes and runtime V2 specifically here: https://docs.railway.com/reference/runtime

I'm glad you got it working

Thanks a lot for the explanation. Have a good day

No problem, you too!

After changing from Legacy to V2, my web app has become very slow (It can even end up with an Internal Server Error). What should I do?

Do you have a database that you're querying to on routes to your web app?

Yes, Postgrees

Railway metal doesn't support volumes yet so your database and web app is now deployed in different regions
I found in my services that it adds about 20ms delay to database queries
don't worry though this is only until metal supports volumes- then everything will be back to normal

If it's noticeable enough to cause issues then something is probably wrong with your configuration, likely culprit is the private network
are you connected to your database under the private network?

Here is the log:

response = self.get_response(request)

Dec 23 09:00:53

File "/opt/venv/lib/python3.10/site-packages/django/core/handlers/exception.py", line 55, in inner

Dec 23 09:00:53

response = get_response(request)

Dec 23 09:00:53

File "/opt/venv/lib/python3.10/site-packages/django/core/handlers/base.py", line 197, in getresponse

Dec 23 09:00:53

response = wrapped_callback(request, callback_args, *callback_kwargs)

Dec 23 09:00:53

File "/app/braket_class/views.py", line 46, in braket_class_home_level

Dec 23 09:00:53

if r.kelas not in pelajarans and r.kelas not in tmp_kelas:

Dec 23 09:00:53

File "/opt/venv/lib/python3.10/site-packages/django/db/models/fields/related_descriptors.py", line 257, in get

Dec 23 09:00:53

rel_obj = self.get_object(instance)

Dec 23 09:00:53

File "/opt/venv/lib/python3.10/site-packages/django/db/models/fields/related_descriptors.py", line 220, in get_object

Dec 23 09:00:53

return qs.get(self.field.get_reverse_related_filter(instance))

Dec 23 09:00:53

File "/opt/venv/lib/python3.10/site-packages/django/db/models/query.py", line 645, in get

Dec 23 09:00:53

num = len(clone)

Dec 23 09:00:53

File "/opt/venv/lib/python3.10/site-packages/django/db/models/query.py", line 382, in len

Dec 23 09:00:53

self._fetch_all()

Dec 23 09:00:53

File "/opt/venv/lib/python3.10/site-packages/django/db/models/query.py", line 1928, in fetchall

Dec 23 09:00:53

self._result_cache = list(self._iterable_class(self))

Dec 23 09:00:53

File "/opt/venv/lib/python3.10/site-packages/django/db/models/query.py", line 91, in iter

Dec 23 09:00:53

results = compiler.execute_sql(

Dec 23 09:00:53

File "/opt/venv/lib/python3.10/site-packages/django/db/models/sql/compiler.py", line 1574, in execute_sql

Dec 23 09:00:53

cursor.execute(sql, params)

Dec 23 09:00:53

File "/opt/venv/lib/python3.10/site-packages/django/db/backends/utils.py", line 122, in execute

Dec 23 09:00:53

return super().execute(sql, params)

Dec 23 09:00:53

File "/opt/venv/lib/python3.10/site-packages/django/db/backends/utils.py", line 79, in execute

Dec 23 09:00:53

return self._execute_with_wrappers(

Dec 23 09:00:53

File "/opt/venv/lib/python3.10/site-packages/django/db/backends/utils.py", line 92, in executewith_wrappers

Dec 23 09:00:53

return executor(sql, params, many, context)

Dec 23 09:00:53

File "/opt/venv/lib/python3.10/site-packages/django/db/backends/utils.py", line 105, in _execute

Dec 23 09:00:53

return self.cursor.execute(sql, params)

Dec 23 09:00:53

File "/root/.nix-profile/lib/python3.10/encodings/utf_8.py", line 15, in decode

Dec 23 09:00:53

def decode(input, errors='strict'):

Dec 23 09:00:53

File "/opt/venv/lib/python3.10/site-packages/gunicorn/workers/base.py", line 204, in handle_abort

Dec 23 09:00:53

sys.exit(1)

Dec 23 09:00:53

SystemExit: 1

Dec 23 09:00:53

[2024-12-23 02:00:49 +0000] [964] [INFO] Worker exiting (pid: 964)

Dec 23 09:00:53

[2024-12-23 02:00:50 +0000] [1012] [INFO] Booting worker with pid: 1012

Sorry, I don't fully understand what you talking about, my database is on Railway also.

Previously (before changing to v2) it work well.

How are you connecting to your database? Does the connection string contain railway.internal or proxy.rlwy.net?

Where is to check this connection string?

How are you connecting to your database if you don't know where the connection string is?

On database settings the networking:

Public networking: junction.proxy.rlwy.net:14806

Private networking: postgres.railway.internal

Well, yea we want to know if you're connecting to it via the public network or the private network, so which one of those hosts are you using to connect?

I am not sure, where should I see that connection?

The PGHOST is: postgres.railway.internal

Ah if you're building the connection via PGHOST, PGPORT, ... etc then you're using the private network to connect
Meaning your current configuration would then be correct

It's odd that your site would be this slow then, it shouldn't be adding that much delay
Are you querying the database multiple times on a single route? Are you creating a new connection on every query?

Yeah, sometimes it's can load the page but become super slow, and ends up with Internal Server Error

The recent change only moved the region your web app is running in which is now separate from your database, the distance between the two is not large though it's still in the general US-WEST region meaning it's not that much of an additional delay.

That being said, your configuration is correct and there's nothing else on Railway you can do to fix this issue, from here you'll have to diagnose within your code regarding what could be causing internal server errors from just a minor additional delay in database queries. I won't be able to help much from here on out unfortunately

Very sorry that this Railway platform change is affecting your build, don't worry though - volume support for metal is around the corner and so this additional delay won't exist for much longer. From here all I can recommend is diagnosing the issue within your code itself to see if you can find what's causing the errors

Note: if this is a mission critical application, then I'd recommend you upgrade to pro plan - you'll be able to freely change the regions which will patch your issue if you set the web app's region back to us-west-oregon

About this question

"Are you querying the database multiple times on a single route? Are you creating a new connection on every query?"

The app is Django app, It should not making new connection every time

Oh alright, I'm not very familiar with django since I don't code in python much, sorry about that

what do I do know though is that your Railway related configurations is correct and that the rest will require debugging your code

Sorry I couldn't be of more help here

Thanks for your help, I have set the CONN_MAX_AGE of my django database connection to 600 (10 minutes) and still very very slow and ends up with internal server error. If you have any information about it, really appreciate. Again thanks a lot

Of course, very sorry that metal is causing issues for you and I really appreciate your patience here!

As far as we know there is no platform issues that could be causing slowness to that degree, query time increases should be minimal from metal deployments to databases but if any news comes through then I'll update you here

I'm going to mark as solved in the mean-time since the original question was answered

Many thanks and looking forward for the solution