Earlier quoted context omitted.
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).
I think what you’re saying is that if OP were to test your site from Helsinki they would see the server speed you’re talking about. Is that right?
Serving a high-performance blog solely from memory, using Rust
101–110 of 143 posts
Re: Serving a high-performance blog solely from memory, using Rust
#102I want to see this taken to the logical extreme. A real OS with actual drivers (no unikernel, no virtio) for a small set of hardware that only serves static pages. No need for virtual memory. Just hardcode the blog posts right into the OS and use the most minimal TCP stack you can make.
Re: Serving a high-performance blog solely from memory, using Rust
#103I admire the OP's ability to use their blog as a rapid prototyping platform that is constantly growing and changing. Over engineering on a personal project like this is the whole point! Very cool. I am too much of an OCD perfectionist and don't have the guts to ship this often.
The trick is to do lots of little changes that are easy to do in isolation. Then do bigger changes later after you learn what you messed up. I have CDO too but I work around it by sheer trolling with infrastructure, like my hacked up to hell CDN: https://xeiaso.net/blog/xedn
A lot of our (and in particular, my) best features come from of relocating the boundaries between things, to make space for features that weren't considered in the original design. With monolithic systems we see this late in the lifecycle in the form of Conway's Law. If you stick this problem in front of the CI/CD mirror, it's painful to face. CI/CD argues that if something is difficult we should do it all the time so that it's routine (or stop doing it entirely).
However there's a conspicuous lack of tools and techniques to make that practical. The only one I really know of is service retirement (replace 2-3 services with 2 new, refactored services), and we don't have static analysis tools that can tell us deterministically when we can remove an API. We have to do it empirically, which is fundamentally on par with println debugging.
Re: Serving a high-performance blog solely from memory, using Rust
#104I want to see this taken to the logical extreme. A real OS with actual drivers (no unikernel, no virtio) for a small set of hardware that only serves static pages. No need for virtual memory. Just hardcode the blog posts right into the OS and use the most minimal TCP stack you can make.
Re: Serving a high-performance blog solely from memory, using Rust
#105Earlier quoted context omitted.
That “traditional” site doesn’t actually load the data from disk, in practice. It does once, after a reboot, but that’s true for this solution’s executable file as well. Does Apache/Nginx/IIS load static files in memory ahead of time? I would assume no, unless someone went through and did some optimizations. Even so, there is always a point where memory runs out, and in that case a templating engine is essentially co…
Author here. I don't identify as male. It would be nice if you could update your comment to not make a factual error when referring to me. Please use https://pronoun.is/they . Thanks!
Re: Serving a high-performance blog solely from memory, using Rust
#106Earlier quoted context omitted.
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.
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.
Re: Serving a high-performance blog solely from memory, using Rust
#107How can it be faster than a static page that is already in memory, the bytes are there you just send them over a socket? Transforming some template to rust code back to string buffer is somehow faster?
My thoughts as CDN engineer: It can be a tiny amount more efficient since an async disk IO implementation might dispatch the file read() call to a thread pool, wait for the result, and then send the data back to the client. Makes 2 extra context switches compared to sending data from memory. Now if the user is super confident that the data is hot and in page cache then a synchronous disk read will fix the problem. Or…
Re: Serving a high-performance blog solely from memory, using Rust
#108I want to see this taken to the logical extreme. A real OS with actual drivers (no unikernel, no virtio) for a small set of hardware that only serves static pages. No need for virtual memory. Just hardcode the blog posts right into the OS and use the most minimal TCP stack you can make.
Re: Serving a high-performance blog solely from memory, using Rust
#109Re: Serving a high-performance blog solely from memory, using Rust
#110Earlier quoted context omitted.
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.
would a satellite to satellite laser in low earth orbit be faster than a radio link between the same satellites?