seeing unexpectedly high latency!

3 months ago

I'm trying to serve a faster API for users, but I'm seeing unexpectedly high latency — even on a simple health endpoint.

I'm using Hono with Bun, and the route is extremely small:

app.get("/health", (c) => c.json({ status: "ok", service: "auth" }));

The server is running with Bun like this:

export default {
  fetch: app.fetch,
  port: 3000,
  hostname: '::',
  keepAlive: 60_000,
  idleTimeout: 70,
  headersTimeout: 71,
}

However, the metrics I'm getting from curl are surprisingly slow:

$ curl -w "namelookup:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n" -o /dev/null -s https://api.mestra.chat/health

namelookup:0.285863 connect:0.286653 tls:0.582073 ttfb:1.290903 total:1.291382

$ curl -w "namelookup:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n" -o /dev/null -s https://api.mestra.chat/health

namelookup:0.003992 connect:0.004488 tls:0.304845 ttfb:0.674463 total:0.674929

Even for a static /health response, I’m getting ~600–1300ms total time, which feels too high.
I’m trying to understand whether the latency is coming from DNS, TLS handshake, Bun’s server, or something else in the network path.

Any suggestions on how to diagnose or optimize this would be greatly appreciated.

Solved

14 Replies

Railway
BOT

3 months ago

Hey there! We've found the following might help you get unblocked faster:

If you find the answer from one of these, please let us know by solving the thread!


3 months ago

cloudflare workers metrics

curl -w "namelookup:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n" -o /dev/null -s https://cf.userdehghani.workers.dev/

namelookup:0.011472 connect:0.126053 tls:0.280923 ttfb:0.450037 total:0.455534


Hey,

This sounds like a routing issue. Can you give us some more diagnostic information and run a few commands for me?

  • The x-railway-edge header from your http request

  • traceroute to 66.33.22.11

  • traceroute to 66.33.22.1

  • The deployment ID that is experiencing the issue


Status changed to Awaiting User Response Railway 3 months ago


3 months ago

X-Railway-Edge: railway/us-east4-eqdc4a

deploymentId: f9801a8e-215b-4ec0-9ceb-74817e12266b

user traceroute:

traceroute 66.33.22.11

traceroute to 66.33.22.11 (66.33.22.11), 64 hops max, 40 byte packets

 1  * * *

 2  * * *

 3  10.185.153.65 (10.185.153.65)  43.321 ms  25.092 ms  22.947 ms

 4  10.155.147.5 (10.155.147.5)  32.242 ms  36.802 ms  33.353 ms

 5  10.0.80.200 (10.0.80.200)  36.832 ms  31.734 ms  23.668 ms

 6  10.0.81.97 (10.0.81.97)  37.518 ms  40.183 ms  28.105 ms

 7  10.0.81.237 (10.0.81.237)  21.261 ms  27.156 ms  45.001 ms

 8  10.0.81.244 (10.0.81.244)  68.896 ms  25.398 ms  24.306 ms

 9  10.202.6.92 (10.202.6.92)  29.412 ms  28.082 ms  20.881 ms

10  10.21.41.12 (10.21.41.12)  32.285 ms  331.257 ms  26.356 ms

11  ix-et-4-0-5-0.tcore2.fnm-frankfurt.as6453.net (195.219.87.198)  107.573 ms  103.541 ms  99.063 ms

12  if-bundle-55-2.qcore2.fnm-frankfurt.as6453.net (195.219.87.57)  95.843 ms *  123.077 ms

13  if-bundle-66-2.qcore1.fr0-frankfurt.as6453.net (195.219.220.128)  188.492 ms *  110.022 ms

14  * 80.231.65.23 (80.231.65.23)  111.745 ms  100.767 ms

15  ae1.3101.ear7.ams1.neo.colt.net (171.75.9.165)  106.693 ms  110.732 ms  107.994 ms

16  lumen-techn.ear7.amsterdam1.level3.net (212.133.96.222)  96.475 ms  104.279 ms  100.039 ms

17  * * *

18  * * *

19  * * *

20  * * *

21  * * *

22  * * *

23  * * *

24  * * *

25  * * *

26  * * *

27  * * *


Status changed to Awaiting Railway Response Railway 3 months ago


3 months ago

another unexpected things, simplest select and update query on database with internal connection take 31s long to response.
This happens time to time but it's really strange.

is there any cold start feature like serverless functions? if it is,i need to turn it off!

{
  "message": "--> POST /auth/verify-otp \u001b[32m200\u001b[0m 31s",
  "attributes": {
    "level": "info"
  },
  "tags": {
    "project": "392a5079-4981-4e79-b0c5-b09896e83b70",
    "environment": "dae40a4f-a632-4b45-92d5-b6e6bb9d7e72",
    "service": "df7efdeb-b2bf-4500-b19c-bb618634b843",
    "deployment": "f9801a8e-215b-4ec0-9ceb-74817e12266b",
    "replica": "effda741-8eea-49f3-8b90-4c300c9958dc"
  },
  "timestamp": "2025-12-04T10:10:11.639212275Z"
}

Anonymous
PRO

3 months ago

Same here
My service, n8n, is very very slow, like unusable


Same hereMy service, n8n, is very very slow, like unusable

3 months ago

Could you create your own thread and link it here please? pray emoji


Status changed to Awaiting User Response Railway 3 months ago


userdeh

X-Railway-Edge: railway/us-east4-eqdc4adeploymentId: f9801a8e-215b-4ec0-9ceb-74817e12266buser traceroute:traceroute 66.33.22.11traceroute to 66.33.22.11 (66.33.22.11), 64 hops max, 40 byte packets1  * * *2  * * *3  10.185.153.65 (10.185.153.65)  43.321 ms  25.092 ms  22.947 ms4  10.155.147.5 (10.155.147.5)  32.242 ms  36.802 ms  33.353 ms5  10.0.80.200 (10.0.80.200)  36.832 ms  31.734 ms  23.668 ms6  10.0.81.97 (10.0.81.97)  37.518 ms  40.183 ms  28.105 ms7  10.0.81.237 (10.0.81.237)  21.261 ms  27.156 ms  45.001 ms8  10.0.81.244 (10.0.81.244)  68.896 ms  25.398 ms  24.306 ms9  10.202.6.92 (10.202.6.92)  29.412 ms  28.082 ms  20.881 ms10  10.21.41.12 (10.21.41.12)  32.285 ms  331.257 ms  26.356 ms11  ix-et-4-0-5-0.tcore2.fnm-frankfurt.as6453.net (195.219.87.198)  107.573 ms  103.541 ms  99.063 ms12  if-bundle-55-2.qcore2.fnm-frankfurt.as6453.net (195.219.87.57)  95.843 ms *  123.077 ms13  if-bundle-66-2.qcore1.fr0-frankfurt.as6453.net (195.219.220.128)  188.492 ms *  110.022 ms14  * 80.231.65.23 (80.231.65.23)  111.745 ms  100.767 ms15  ae1.3101.ear7.ams1.neo.colt.net (171.75.9.165)  106.693 ms  110.732 ms  107.994 ms16  lumen-techn.ear7.amsterdam1.level3.net (212.133.96.222)  96.475 ms  104.279 ms  100.039 ms17  * * *18  * * *19  * * *20  * * *21  * * *22  * * *23  * * *24  * * *25  * * *26  * * *27  * * *

3 months ago

Where are you connecting from?


ray-chen

Where are you connecting from?

3 months ago

our users mostly from Middle East


Status changed to Awaiting Railway Response Railway 3 months ago


3 months ago

Are you or any of your users able to follow the steps and attach the output here? https://docs.railway.com/reference/network-diagnostics


Status changed to Awaiting User Response Railway 3 months ago


ray-chen

Are you or any of your users able to follow the steps and attach the output here? https://docs.railway.com/reference/network-diagnostics

3 months ago

users area


Railway Network Diagnostics
Generated : Saturday, Dec 6 2025 10:16:24 +0330
Endpoint  : routing-info-production.up.railway.app


-------------------------------------------------------------------------------
Client IP Info
-------------------------------------------------------------------------------
{
  "status": 429,
  "error": {
    "title": "Rate limit exceeded",
    "message": "You've hit the daily limit for the unauthenticated API.  Create an API access token by signing up to get 50k req/month."
  }
}

-------------------------------------------------------------------------------
HTTP HEAD request
-------------------------------------------------------------------------------
Status: 200 OK
Status Code: 200
Protocol: HTTP/2.0

Response Headers:
  Content-Type: text/html
  Date: Sat, 06 Dec 2025 06:46:27 GMT
  Server: railway-edge
  X-Railway-Edge: railway/europe-west4-drams3a
  X-Railway-Request-Id: O7_2IQ57TqiTu8Zrss7a6g


-------------------------------------------------------------------------------
DNS lookup (using system DNS)
-------------------------------------------------------------------------------

; <<>> DiG 9.10.6 <<>> routing-info-production.up.railway.app
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64431
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;routing-info-production.up.railway.app.	IN A

;; ANSWER SECTION:
routing-info-production.up.railway.app.	60 IN A	66.33.22.232

;; Query time: 146 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sat Dec 06 10:16:25 +0330 2025
;; MSG SIZE  rcvd: 83



-------------------------------------------------------------------------------
DNS lookup (using Cloudflare)
-------------------------------------------------------------------------------

; <<>> DiG 9.10.6 <<>> @1.1.1.1 routing-info-production.up.railway.app
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9526
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;routing-info-production.up.railway.app.	IN A

;; ANSWER SECTION:
routing-info-production.up.railway.app.	418 IN A 10.10.34.36

;; Query time: 12 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Sat Dec 06 10:16:25 +0330 2025
;; MSG SIZE  rcvd: 72



-------------------------------------------------------------------------------
Traceroute
-------------------------------------------------------------------------------
 1  * *
 2  81.91.153.241 (81.91.153.241)  9.407 ms  5.021 ms
 3  172.27.18.17 (172.27.18.17)  47.239 ms  14.817 ms
 4  172.27.16.193 (172.27.16.193)  10.398 ms  19.870 ms
 5  172.21.2.70 (172.21.2.70)  21.920 ms  6.030 ms
 6  172.21.2.153 (172.21.2.153)  62.851 ms  50.087 ms
 7  172.20.21.105 (172.20.21.105)  6.301 ms  6.183 ms
 8  172.20.40.38 (172.20.40.38)  6.283 ms  16.164 ms
 9  * *
10  * *
11  10.202.6.198 (10.202.6.198)  11.945 ms  11.256 ms
12  10.21.212.10 (10.21.212.10)  13.990 ms  7.724 ms
13  213.144.184.62 (213.144.184.62)  97.190 ms  77.533 ms
14  89.221.34.189 (89.221.34.189)  87.876 ms  88.595 ms
15  ae1.3101.ear7.ams1.neo.colt.net (171.75.9.165)  84.206 ms  83.067 ms
16  lumen-techn.ear7.amsterdam1.level3.net (212.133.96.222)  93.452 ms  86.930 ms
17  66.33.22.232 (66.33.22.232)  87.790 ms  89.531 ms


-------------------------------------------------------------------------------
Ping (n=10)
-------------------------------------------------------------------------------
PING routing-info-production.up.railway.app (66.33.22.232): 56 data bytes
64 bytes from 66.33.22.232: icmp_seq=0 ttl=45 time=88.146 ms
64 bytes from 66.33.22.232: icmp_seq=1 ttl=45 time=88.461 ms
64 bytes from 66.33.22.232: icmp_seq=2 ttl=45 time=96.481 ms
64 bytes from 66.33.22.232: icmp_seq=3 ttl=45 time=86.555 ms
64 bytes from 66.33.22.232: icmp_seq=4 ttl=45 time=88.591 ms
64 bytes from 66.33.22.232: icmp_seq=5 ttl=45 time=86.634 ms
64 bytes from 66.33.22.232: icmp_seq=6 ttl=45 time=92.278 ms
64 bytes from 66.33.22.232: icmp_seq=7 ttl=45 time=85.838 ms
64 bytes from 66.33.22.232: icmp_seq=8 ttl=45 time=88.468 ms
64 bytes from 66.33.22.232: icmp_seq=9 ttl=45 time=107.308 ms
--- routing-info-production.up.railway.app ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 85.838/90.876/107.308/6.243 ms


Completed

Status changed to Awaiting Railway Response Railway 3 months ago



3 months ago

I moved the services to EU West (Amsterdam),

which reduced latency from ~600–1300ms down to about ~350–600ms.

I also enabled Keep-Alive and applied several additional optimizations.

However, there’s still a significant gap before we can reach the performance levels that CF Workers provide by default.


3 months ago

Your traceroute looks normal. The latency is to be expected if connecting from the Middle East because they're currently routed to Amsterdam at the moment. Unfortunately we don't have a short-term solution for this - if performance is critical here, I would recommend sticking with CF workers.


Status changed to Awaiting User Response Railway 3 months ago


Status changed to Solved userdeh 3 months ago


Status changed to Solved userdeh 3 months ago


Loading...