[jmillikin]

There may be further opportunities for improvement.

Chrome and Curl both report it takes about 1100ms to load the linked page's HTML, split about 50/50 between establishing a connection and fetching content. I'm not sure how the implementation works internally but that seems like a long time for a site served from memory and aiming to be "high-performance". The images bring the total time up to around 5.7s.

As a point of comparison, my site (nginx serving static content, on the 0.25 CPU GCP instance) serves the index page in 250ms. Of that, ~140ms is connection setup (DNS, TCP, TLS). The whole page loads in < 1000ms.

https://i.imgur.com/X4LDbWj.png

https://i.imgur.com/Ccwzmgz.png

One thing to remember is that when a server like nginx serves static content, it's often serving it from the page cache (memory). The author of Varnish has written at some length about the benefits of using the OS page cache, for example <https://varnish-cache.org/docs/trunk/phk/notes.html>. Some of the same principles can be applied even for servers that render dynamically (by caching expensive fragments).

[xena]

Author here. I wrote that post before I axed the CDN for my blog site itself. It was true at the time of writing, but it is not true anymore because I need to redo the CDN for the blog itself. All the images are CDNed with XeDN though.

[georgyo]

I'm trying to parse what you are saying here.

You removed the CDN and the site got slower?

How do you know your site was the one that was fast or just the CDN? IE, the CDN should have added a lot of extra hops and made things slower.

To me, this implies the rust code is very poor at opening and closing connections, so the CDNs keep alive is pasting over that issue.

[xena]

The main thing the CDN provided was nodes on basically every continent that kept the site in cache. Without those servers on every continent keeping the site in cache, it takes longer to get to the netherlands to get the site loaded. The speed of light is only so fast.

[hn92726819]

If they are keeping your article cached, what's the point of saying it's a high-performance blog? Saying it's slow because the CDN down means that it's just slow... You can have a 'high performance' blog run on a raspberry pi zero if it's globally cached by someone else, but then I wouldn't say that's high performance.

Cool article though. Agree on the ructe part, and I dislike how whitespace is handled. I wish Jade/Pug templates could be done in rust but will check out Maud.

[xena]

The blog itself is fast. The internet is the slow part.

[xena]

I thought of a better way to phrase it. The website itself is fast, but the process of you observing the website is slow because of limitations of the speed of light (or other interconnects the internet uses to get your traffic to Helsinki).

[progrus]

And probably more importantly, routing packets through international traffic all the way to the Netherlands takes a while too.

[MuffinFlavored]

> The speed of light is only so fast.

Is the Internet not connected internationally (US -> Europe for example) via cables underneath the ocean? Speed of light would be satellite, light? Not electric current?

Or is electricity flowing through a wire also "speed of light"?

[tsimionescu]

First of all, the "speed of light" is usually referring to c, the maximum speed that matter or energy can move at.

Second of all, electrical signals in cables move at speeds slightly lower than c, but very close to it, so the speed of light is still a very good approximation of the possible upper bound.

Third of all, intercontinental cables are normally fiber optic, for several reasons. That is, they directly transmit light through the cable.

Fourth, it should be noted that electricity is actually the same thing as light, since photons are the carrier particles of the electric field (when two charged particles interact, they are actually exchanging a photon). It's of course not visible light, but satellite communication also uses radio waves normally, which are not visible light either.

Finally, either through cables or through satellite communication, the distance/c minimum theoretical one-way latency is usually a significant under-estimation of the actually possible minimal latency, since the straight-line distance is significantly shorter than the actual cable/satellite-and-back distance that the signals must travel - the difference in straight-line VS physical path distance is typically much larger than the difference between the theoretical speed of light and the actual speed of the electrical signal propagation.

[hinkley]

We tend to think of wires as a garden hose for electrons, but it's the EM field that propagates, moreso than the electrons. Especially for AC power and for signals.

[potatochup]

Most (all?) Intercontinental cables will be fibre optic. So it's the speed of light (in glass, not a vacuum)

[xena]

I'm not an expert in cross-continent interconnects, I have no idea what cables are being used there. I'd imagine that a lot of the backbone of the internet is fiber because that's what all the SRE memes say about wandering backhoes and sharks being the primary predator of fiber optic cables.

[Matthias247]

Nothing is faster than speed of light. In fact signals transmitted via copper wires are traveling at 2/3 the speed of light. Don't know the details about fiber ocean links, but it certainly won't be faster than speed of light.

[spullara]

Fiber optics are also about 2/3rds the speed of light. One of the interesting things about Starlink is that when they have laser links between satellites they should be able to beat terrestrial latencies over very long distances like California to London.

[pkhuong]

These cables are fiber optics, but either way, the speed of light is still a bound.

[Groxx]

As a contrasting point: I'm consistently getting 150ms from their main domain, and 25-35ms from their cdn subdomain. I suspect most of your latency is from "the internet".