undefined | Better HN

0 pointskiwijamo2y ago0 comments

It is not. A simple traceroute shows traffic from Auckland, New Zealand is routed all the way to the San Diego via Los Angeles. Cloudflare sites typically have traceroutes terminating here at Auckland (best case scenario) or in some cases across the pond in Sydney, Australia.

It is interesting to note however I don't observe much latency issues despite a 130ms round trip.

0 comments

re-thc2y ago

~150ms is usually acceptable especially if there's no Javascript and other extra delays. >=200ms is usually. where it really shows.

littlestymaar2y ago

Keep in mind that 150ms round-trip latency means at least 600ms latency when opening a webpage because of the TCP and TLS handshake.

But even 600ms is OK on today's web (or even on today's desktop apps it seems…)

re-thc2y ago

> Keep in mind that 150ms round-trip latency means at least 600ms latency when opening a webpage because of the TCP and TLS handshake.

The solution there is use a CDN, even for the API. Or some anycast IP solution like Global Accelerator (AWS), Global load balancer (GCP) or Front Door (Azure).

You connect to the nearest region for HTTPS handshake and then that takes the "fastest" route back to your origin.

There's a video from AWS documenting how Slack did exactly that: youtube.com/watch?v=oVaTiRl9-v0

j / k navigate · click thread line to collapse

0 pointskiwijamo2y ago0 comments

It is interesting to note however I don't observe much latency issues despite a 130ms round trip.

0 comments

re-thc2y ago

~150ms is usually acceptable especially if there's no Javascript and other extra delays. >=200ms is usually. where it really shows.

littlestymaar2y ago

Keep in mind that 150ms round-trip latency means at least 600ms latency when opening a webpage because of the TCP and TLS handshake.

But even 600ms is OK on today's web (or even on today's desktop apps it seems…)

re-thc2y ago

> Keep in mind that 150ms round-trip latency means at least 600ms latency when opening a webpage because of the TCP and TLS handshake.

The solution there is use a CDN, even for the API. Or some anycast IP solution like Global Accelerator (AWS), Global load balancer (GCP) or Front Door (Azure).

You connect to the nearest region for HTTPS handshake and then that takes the "fastest" route back to your origin.

There's a video from AWS documenting how Slack did exactly that: youtube.com/watch?v=oVaTiRl9-v0

j / k navigate · click thread line to collapse