2 months ago
Hi, I'm experiencing ~50ms TCP round-trip times between my app service and Postgres service on Railway's internal network (postgres.railway.internal).
Measurements from inside the app container:
Raw TCP connect (no query, just socket open)
time php -r "$s = fsockopen('postgres.railway.internal', 5432); fclose($s);"
Results: 207ms, 52ms, 47ms across 3 runs
PDO connection
time php -r "new PDO('pgsql:host=postgres.railway.internal;port=5432;...');"
Results: 256ms, 106ms, 262ms, 260ms across 4 runs
For comparison, curling my own app internally is 20ms, so the app itself is fast. The latency is purely between services.
Details:
- App region: europe-west4-drams3a
- Project: Tijdist (ID: 3a3dfe8b-a796-4165-9829-8b5180779e68)
- Service: 2b3b3a6e-9cca-41b2-9f28-b755f15d4adb
This was previously working fine (<100ms full page loads). After a recent redeploy, authenticated pages now take 300ms+ due to the accumulated latency across multiple DB queries.
Are my app and Postgres services in the same availability zone? Is there anything that can be done to reduce the internal networking latency?
1 Replies
2 months ago
This thread has been marked as public for community involvement, as it does not contain any sensitive or personal information. Any further activity in this thread will be visible to everyone.
Status changed to Open Railway • 2 months ago
2 months ago
The latency you're seeing (~50ms RTT) is unusually high for internal networking and suggests a routing mismatch or "unlucky" placement of your containers across Availability Zones (AZs).
1. Force AZ Realignment (The "Redeploy" Fix)
Railway doesn't let you manually pick an AZ, but you can force the scheduler to re-evaluate placement.
- Action: Go to your Postgres service settings, change a minor resource limit (e.g., increase RAM by 10MB), and redeploy.
- Follow-up: Once the DB is healthy, redeploy your App service. This often co-locates them on the same physical hardware or at least within the same AZ, which should drop that 50ms RTT to <5ms.
2. Fix PHP/PDO Connection Overhead
Your test shows a huge jump from 47ms (TCP) to 260ms (PDO). This confirms that the SSL/TLS handshake and Postgres Authentication are compounding the network delay.
- Action: Enable Persistent Connections in your PHP PDO string to avoid a fresh handshake on every request. Code Changes: $options = [PDO::ATTR_PERSISTENT => true]; new PDO('pgsql:host=postgres.railway.internal;port=5432;...', $user, $pass, $options);
3. Optimize Alpine/DNS (If applicable)
If your PHP app is running on an Alpine Linux image (very common for PHP-FPM), the internal DNS resolver can be slow.
- Action: Add this Environment Variable to your App service:
ENABLE_ALPINE_PRIVATE_NETWORKING=true - Alternative: Use the internal IP address directly for a test run to see if the latency stays the same. If it drops, the issue is Railway's internal DNS resolver (
CoreDNS) in that region. 4. Verification Command Run this inside your app container to see if the "Network Hop" is the culprit:traceroute postgres.railway.internal