Hacker News Reader

Comment by mrkurt | Hacker News Reader

The thing we do that's (maybe) interesting is run processes all over the world. It's helpful for liveview because it minimizes latency to end users. Here's an example Liveview cluster running in 17 regions, if you scroll down you'll see the round trip time to the server you're connected to: https://liveview-counter.fly.dev/

Liveview is crazy powerful if you can keep the latency down.

View on HN

That is extremely interesting. I've never seen a cloud provider that prominently advertised Anycast IP addresses.

LiveView should already have less latency than an app doing traditional AJAX requests, since an open web socket is a lot better than making a call to axios!

The less latency the better, though, of course. I'm seeing roughly 80ms, which is very good.

HTTP with keep-alive supports keeping around idle connections, which can be used to make subsequent AJAX calls.

HTTP/2 has this by default, and allows multiplexing multiple requests on a single connection, so even making multiple parallel calls won't require establishing new connections.

Basically, performance between AJAX and web sockets should be comparable in most cases.

Nice demo! How is the server chosen? I'm seeing ~200ms latency. I'm connected to LAX which I don't think would be shortest round trip.

Where are you connecting from, out of curiosity? 200ms is poor!

Fly apps get anycast IPs, so it's basically bgp getting you to our "nearest" edge proxy, then we connect you to the closest vm from there.

https://debug.fly.dev will show you which region you hit first (the fly-region request header).

--edit--

I snooped on your HN profile and found Australia. We don't have an instance of this app up in AU, but we could. You're likely connecting to us in Sydney, and LAX is most likely the fastest over our backhaul from there.

I am connecting from India and my latency is about ~180ms

In a couple of months we'll have instances in Chennai!

I'm connecting from Sweden and got about 40 ms. But now and then it peaks to 4000-8000 ms while my ping within the city stays at 2 ms.

Those spikes are hilarious, they're probably from a liveview DoS. People are fond of using the debug console to "click" hundreds of times per second and there's no rate limiting in the app.

From Finland: Through LTE I get served via 'fra' with ~60ms (as one might expect). However if I switch to Wifi I get 'hkg' with ~260ms?? Not exactly next-door :)

Same here in Norway :)

Would you mind emailing me with your IP address and a screenshot of what you see at https://debug.fly.io when you're on wifi? Finland to hkg is not what we want to be doing.

kurt fly.io

(not op) Is that link wrong? I'm getting ERR_NAME_NOT_RESOLVED. I tried with Vodafone mobile (UK), Openreach Wifi (UK), and a few other countries over a VPN (Canada, Australia, ...) in Firefox and Chrome.

There's https://debug.fly.dev/.

Oops, yes this.

I’m in Brisbane and was expecting Singapore would be closer. Thanks for the reply.

I'm not sure if this is in the realms of what Fly could do easily but I love the idea that for this kind of Liveview app you could monitor where your users actually are dynamically set up a close node to reduce latency.

Bonus points if you could bring the node down again when usage drops.

This is actually how our autoscaling works. Since it works based on concurrent connections, it should be pretty good fore Liveview apps.

https://fly.io/docs/reference/scaling/#autoscaling

I like that you can mount a volume to a region, render can only do a single instance.

Fyi at least on mobile the buttons stay focused after tap, making it look (incorrectly) like the ack is lagging.

Reply on news.ycombinator.com