Slow dns lookup to custom domain

We’re having the network folks look into this.

Where are you currently running your app? If you run it in seattle (for now) you’ll get a faster result. It should be <300ms from Korea to Seattle.

1 Like

This should be better now. Our network provider tells us you should be routed through Tokyo now (which is probably our closest node).

1 Like

Thanks very much to both of you!
I believe you’ve resolved the issue, and response times are as expected.

1 Like

I used turboku to experiment migrating to flyio, the results are not promising, not sure what I am doing wrong here.

I am noticing similar issues, fly.dev takes seconds to load:

Heroku is consistently faster for all requests:

Can you expand that first request and see what the breakdown is? That’s incredibly slow.

Also, check what regions your app is running in with fly status. It should be something very close to your Redis instance. It seems like all those requests are much slower than the corresponding Heroku version. That looks almost like what I’d expect if the Sidekiq process is talking to a Redis that’s in a different region.

Sure I can give a bit more information.

I am using Cloudflare for my DNS, for now it’s not proxy (no orange cloud, I plan on turning it on eventually if possible), the A, AAAA and CNAME DNS records are there and have been verified, if I curl the app, it’s sometimes fast, sometimes super slow.

Slow and crashed:

❯ curl -vvv https://fly.venue.live
*   Trying 37.16.7.89:443...
* Connected to fly.venue.live (37.16.7.89) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
* (304) (OUT), TLS handshake, Client hello (1):
* error:02FFF036:system library:func(4095):Connection reset by peer
* Closing connection 0
curl: (35) error:02FFF036:system library:func(4095):Connection reset by peer

Snappy and fast:

❯ curl -vvv https://fly.venue.live
*   Trying 37.16.7.89:443...
* Connected to fly.venue.live (37.16.7.89) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
* (304) (OUT), TLS handshake, Client hello (1):
* (304) (IN), TLS handshake, Server hello (2):
* (304) (IN), TLS handshake, Unknown (8):
* (304) (IN), TLS handshake, Certificate (11):
* (304) (IN), TLS handshake, CERT verify (15):
* (304) (IN), TLS handshake, Finished (20):
* (304) (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / AEAD-CHACHA20-POLY1305-SHA256
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=fly.venue.live
*  start date: May  6 20:13:27 2022 GMT
*  expire date: Aug  4 20:13:26 2022 GMT
*  subjectAltName: host "fly.venue.live" matched cert's "fly.venue.live"
*  issuer: C=US; O=Let's Encrypt; CN=R3
*  SSL certificate verify ok.
* Using HTTP2, server supports multiplexing
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x151811400)
> GET / HTTP/2
> Host: fly.venue.live
> user-agent: curl/7.79.1
> accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS == 4294967295)!
< HTTP/2 302
< x-frame-options: SAMEORIGIN
< x-xss-protection: 1; mode=block
< x-content-type-options: nosniff
< x-download-options: noopen
< x-permitted-cross-domain-policies: none
< referrer-policy: strict-origin-when-cross-origin
< location: https://fly.venue.live/admin
< content-type: text/html; charset=utf-8
< cache-control: no-cache
< x-request-id: 06f81ced-0698-4b00-8d5a-a4edf5ce6e1a
< x-runtime: 0.002715
< strict-transport-security: max-age=63072000; includeSubDomains
< vary: Origin
< date: Sat, 07 May 2022 00:08:41 GMT
< server: Fly/33deaca5 (2022-05-05)
< via: 2 fly.io
< fly-request-id: 01G2DXHCWDK23FTZKY26N3MMGM-chi
<
* Connection #0 to host fly.venue.live left intact
<html><body>You are being <a href="https://fly.venue.live/admin">redirected</a>.</body></html>%

PS: The comment you made on Redis does make sense as for now I have both PG and Redis from Heroku cluster as I am using turboku to experiment with this migration.