18 days ago
Hello Everyone
We're experiencing significant performance differences between our local environment and our Railway deployment.
Our application stack:
- Backend: Node.js API
- Hosted on: Railway Pro Plan
- Users primarily located in India
Issue:
- The same API endpoints execute very quickly in our local environment.
- When deployed on Railway, response times are noticeably slower.
- The application feels sluggish during normal usage, despite low resource utilization.
Observations:
- Current CPU usage is very low.
- Memory usage is around 500 MB.
- No obvious CPU or memory bottlenecks are visible in the metrics.
- We are on the Railway Pro plan.
- The application is not experiencing high traffic at this time.
Could you help us investigate:
- Which region our service is currently running in?
- Whether there are any network latency issues between our service and Railway infrastructure.
- Whether there are any platform-level throttling, cold-start, or performance limitations affecting the service.
- How we can measure request latency and network latency within Railway.
- Whether you recommend any specific performance diagnostics for our deployment.
If helpful, we can provide:
- Project ID
- Deployment URL
- Example slow endpoints
- Additional logs
Thank you.
5 Replies
18 days ago
Your project does not include a database service, so if your backend connects to an external database, round-trip latency to that database is the most likely factor. You can check your service's current deploy region in the service's Settings under the Scale section, and our closest region to India is Southeast Asia (Singapore) - switching to that if you're currently on a US or EU region will reduce latency for your users. To measure where latency is occurring, use the HTTP log filter @totalDuration:>500 in your project's logs view and compare totalDuration (full round-trip including network) against upstreamRqDuration (your app's processing time) - if upstreamRqDuration is low but totalDuration is high, the latency is in the network path rather than your application. There is no platform-level throttling or cold-start behavior on Pro plan services.
Status changed to Awaiting User Response Railway • 18 days ago
Railway
Your project does not include a database service, so if your backend connects to an external database, round-trip latency to that database is the most likely factor. You can check your service's current deploy region in the service's Settings under the Scale section, and our closest region to India is Southeast Asia (Singapore) - switching to that if you're currently on a US or EU region will reduce latency for your users. To measure where latency is occurring, use the HTTP log filter `@totalDuration:>500` in your project's logs view and compare `totalDuration` (full round-trip including network) against `upstreamRqDuration` (your app's processing time) - if `upstreamRqDuration` is low but `totalDuration` is high, the latency is in the network path rather than your application. There is no platform-level throttling or cold-start behavior on Pro plan services.
18 days ago
i still need help
Status changed to Awaiting Railway Response Railway • 18 days ago
18 days ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • 18 days ago
canacotech
i still need help
18 days ago
Hey, where's your DB hosted? If it's not in the same region as your service, that round-trip latency is almost certainly your issue... locally everything's on one machine so you never see it.
As the bot said, run @totalDuration:>500 and compare upstreamRqDuration vs totalDuration to check where the latency is occurring.
And answering your other questions: There are no network/platform/performance limitations at the moment.
10 days ago
i still need help
10 days ago
You can view the location where your services are hosting by clicking on it and going to the "Settings" tab
Going off the bot it looks like your database is not hosted on Railway. I would recommnend first checking if the region of your database matches (or is at least close to) the region set in the service settings. If this is the case then unfortunately they are just too far apart. If this is the case i'd recommend migrating your database over to Railway, as this will allow you to use their internal network, which lets services talk to eachother a lot faster (as they're in the same datacenter and maybe even on the same machine). When configuring this make sure to use the DATABASE_URL and not the DATABASE_PUBLIC_URL as the public one will stil go over the public net.
Attachments