How to speed up public URL?


#1

In the recent months I am experiencing a slow connection in both image updates and public URL connections.
My Raspberry Pis are downloading node-red pushes in 40-60 minutes on average.

Public URLs for node-red-dashboard takes more than 5mins to load and usually leads to a browser timeout.

Is there a way to improve the speed?


#2

Hi, sorry about that, that is an ongoing investigation.

When you mean Node-RED pushes, that’s through git? If so, might be able to speed it up a bit by using delta updates.

The dashboard slowness can also be related to the software running on the device, we are using a bunch of projects that use public URLs, and are snappy, but there were some that had similar behaviour you mentioned sometimes. (Node-RED should be pretty heavy on the Pis). It’s definitely good to look into it, so it would help if you have any other info, resinOS version, Pi version, if you can share your code that we can deploy the same thing to try, any of these would come handy!


#3

Resin OS is the recent recommended one, I am running electron with node-red embedded mode in a Pi 3.

The Dockerfile is from resin-electronjs, simply adding node-red in the package.json and 10loc in main.js to start node-red.

Yes it is git pushes, the image update can somewhat be tolerated, but node red editor and dashboard can not finish loading without a few reloads by having browser caching the previously loaded resources.

It feels like the connection could only handles 1-2 connections at a time, and even for the live connection it is sending each chunk of 4K data every 10 seconds. It sure looks very much like a throttling network to me.

Electron itself can load above contents without network hiccups in the PI locally.

Since I have no way to test it with a LAN connection, I cannot isolate the problem further down for public URL access.


#4

You man you are not near the device to test it on the LAN? Because if you can access the device through the public URL, then you should be able to access it on the local network going to the device’s local IP over HTTP.

Thanks for the feedback, we are checking this out.

We are not throttling, but the connection does go through US-East, which might be far away from where you are, and not ideal from a latency point of view.


#5

Oh, I tried one with the LAN ip and it fails to connect. I thought it was by design of the resinOS to not directly publish ports to the host system… and I was guessing the whole public URL thing was tunneling the whole container through.

With your words it turns out to be wrong.

US-West is a bit of a route from Hong Kong, I’ll do more on LAN connections.

btw have you thought of expanding to regional load balancing for paid plans?


#6

Just a hint- try ngrok: https://ngrok.com

It’s a lot more flexible, and a lot, lot, lot faster.


#7

Normally whatever port you listen to in your container, you should be able to connect to on the local network (all ports are forwarded to the container). The Public URL is using one specific port to forward, since through that tunnel only one port is easily exposed.

If it fails to connect, then it might be that you are not attaching to all the interfaces (0.0.0.0 in most software, but probably just the loopback device (127.0.0.1), in which case it’s indeed not exposed locally as the loopback is within the device (and the forwarding happens within there). Could try to set the webserver to attach to all network interfaces.

Yeah, HK is pretty far (been using the same thing from Taiwan myself before). Yeah, we talked about more regions and more localized. It gets a bit complex with the global fleets that we see, but definitely on our radar, thanks for the feedback!

And yeah, used ngrok too sometimes, it can work very well depending on your setup and requirements.


#8

A few lines of follow up.

Tried the alternatives mentioned here,

  1. Local IP works like a charm, it didn’t work because the devices are in another subnet.
  2. ngrok is awesome, and I can pick the region too.
  3. Delta updates, it saves about 30% of download time on avg. but still kinda slow (25-40 min depends).

Thanks for the help tho!


#9

That’s strange that delta updates take such a long time, does your container change a lot from version to version? Shouldn’t have to download that much. Delta should take the actual binary difference between the old and new container, and should download the bare minimum to update the container info.


#10

Hey @vicary ,

We have performed a few VPN infrastructure updates recently which should reduce the latency in Device URLS as well as improve SSH speed through the Web terminal and resin ssh.

Please let us know if you see any noticeable improvements from your side.