Live data from Hacker News

Serving a high-performance blog solely from memory, using Rust

xeiaso.net

101–110 of 143 posts

Re: Serving a high-performance blog solely from memory, using Rust

#101
post #65

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?

Yeah, unless I can find a CDN to cache my blog (and maybe its static assets) that would be affordable enough for my needs.

Re: Serving a high-performance blog solely from memory, using Rust

#102

I 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.

One approach is to run some kind of optimizer on a docker image that throws away everything that does not contribute to the end goal of yeeting text at http clients.

Re: Serving a high-performance blog solely from memory, using Rust

#103
post #29

I 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

Relentless Refactoring is a great tool, but one that is often stymied by faddish behaviors like micro-services/modules. Small projects tend not to have that problem and so make a better petri dish. Of course then you have to take your knowledge out of the 'lab' and apply it in vivo...

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

#104

I 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.

Keep on going down that rabbit hole: burn it into an FPGA.

Re: Serving a high-performance blog solely from memory, using Rust

#105
post #60

Earlier 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!

No post body was provided.

Re: Serving a high-performance blog solely from memory, using Rust

#106

Earlier 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.

would a satellite to satellite laser in low earth orbit be faster than a radio link between the same satellites?

Re: Serving a high-performance blog solely from memory, using Rust

#107
post #2

How 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…

The file is most likely cached in memory ( OS ) even if there is a read I assume it's going to be faster vs running some code in Rust.

Re: Serving a high-performance blog solely from memory, using Rust

#108

I 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.

I am actually not sure if a more minimal TCP stack would be the best, especially if you would need to handle packet loss because of congestion for example. For example recent work such as RACK-TLP gives certain workloads better performance, but it is not something you would have in a minimal TCP stack

Re: Serving a high-performance blog solely from memory, using Rust

#109
post #60

Earlier quoted context omitted.

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!

Quoted post unavailable.

No post body was provided.

Re: Serving a high-performance blog solely from memory, using Rust

#110

Earlier 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?

If you mean lower latency by faster, then no.
Post reply on HN