Live data from Hacker News

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

xeiaso.net

31–40 of 143 posts

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

#32
post #18

Earlier quoted context omitted.

If the executable is on disk, it can be paged out unless you've used mlock() to tell the kernel to keep it resident.

Interesting. I've never heard of that happening before. Can you link a reference to where I can find out more about that aspect of the linux memory subsystem?

It's one of the reasons why running without swap can have even worse pathological behaviour than running with swap. With swap the kernel can prioritise keeping code in RAM over little-used data, wheras without it when RAM fills up with data eventually the currently running hot code gets swapped out and performance completely tanks, meaning the system doesn't actually hit the nice OOM error you hope it would. (hence userspace utilities like earlyoom to kick in before the kernel's absolute last resort strategy).

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

#33

Earlier quoted context omitted.

Seems like a case for a unikernel running on bare metal. No copying bytes across kernel/user, no context switching at all.

I guess I didn't realize unikernels could run on bare metal. I've only seen them running on a hypervisor.

I think they typically target hypervisors because it's far more likely that that's what people will want to run on, but there's nothing fundamental stopping a unikernel from running on bare metal.

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

#34

Quoted post unavailable.

There is value in having unsafe parts of a program clearly annotated (not just with comments). It is similar to how in some languages you annotate pure functions and they do not compile unless they are pure.

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

#35
post #20

Earlier quoted context omitted.

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? I don't think the author is claiming it is faster than a static site stored in memory, they're saying it is faster than a traditional static site that loads files from the disk. At least that's how I read it.

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.

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 compression. I would assume if the author outputted his whole website as static files and stored them in memory it would be even faster, but that would require quite a bit more memory.

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

#36
post #30

It would be good if the post contained some data to justify its points, like a graph of loading times. Otherwise assertions like "So fast that it's faster than a static website." don't seem supportable. I would have liked to see the actual results from this comparison: "I compared my site to Nginx, openresty, tengine, Apache, Go's standard library, Warp in Rust, Axum in Rust, and finally a Go standard library HTTP se…

I'm sorry but I have lost that data after some machines got reinstalled. I can attempt to recreate it, but that will have to wait for a future blogpost.

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

#38

Quoted post unavailable.

There is value in having unsafe parts of a program clearly annotated (not just with comments). It is similar to how in some languages you annotate pure functions and they do not compile unless they are pure.

be careful and do your research.

anytime you need to implement anything that shares references (just about any data structure worth its weight in implementation time) you need to use Rc and friends.

i am not talking about https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html. fine, this escape hatch is needed.

i am referring to https://doc.rust-lang.org/book/ch15-06-reference-cycles.html.

Post reply on HN