Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

xeiaso.net

Post reply on HN
Print view View original

21–30 of 143 posts

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

#21

Post by xena »

staticassertion wrote: post #19
trh0awayman wrote: post #13

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.

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

I almost wonder if I should try to get Shrine/TempleOS to do that. That could be a very interesting post.

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

#23

Post by xena »

pradn wrote: post #22

Question for the author: do you have numbers to share about performance relative to other static site servers? Great blog by the way :)

I had the numbers at one point, but I have lost them. I can try to recreate them, but I'd probably have to use my old mac pro again to be sure the results are consistent.

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

#24

Post by xena »

filleokus wrote: post #17
trh0awayman wrote: post #13

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 guess Unikraft is that, kinda? https://github.com/unikraft/app-nginx

I don't see any easy way to get an existing Rust application running on Unikraft. I'll keep an eye out though!

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

#25

Post by whalesalad »

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.

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

#26

Post by staticassertion »

xena wrote: post #18
jmillikin wrote: post #15

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?

I believe that when a file is mmap'd a page table is created for it in the . As you perform read/write on the file a fault loads the actual entries into that page table. As pages can be mapped they so too can be unmapped under pressure, without that falling back to swap (since it is already a file backed map, you wouldn't swap a file backed map to a different file after all).

There are a few relevant bits to this. You can MAP_POPULATE the file to prepopulate the entries and you can MAP_LOCKED to MAP_POPULATE + lock the pages in (unreliably). As mentioned in the man page for mmap MAP_LOCKED has some failure modes that you don't get with mlock.

https://www.man7.org/linux/man-pages/man2/mmap.2.html

I also found this page: https://eklitzke.org/mlock-and-mlockall

Oh, and this: https://access.redhat.com/documentation/en-us/red_hat_enterp...

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

#27

Post by trh0awayman »

staticassertion wrote: post #19
trh0awayman wrote: post #13

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.

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.

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

#28

Post by jmillikin »

xena wrote: post #18
jmillikin wrote: post #15

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?

The mlock manual[0] has a "notes" section that provides a good brief summary. The GNU libc manual has more than anyone would ever want to read about memory management, including a section on memory locking[1].

On an intuitive level, think of swap as being a place the kernel can put memory the program has written. When you malloc(4096) and write some bytes into it, the kernel can't evict that page to disk unless there's some swap space to stick it in. However, executables are different because they're already on disk -- the in-memory version is just a cache (everything is cache (computers have too many caches)). The kernel is allowed to drop the copy of the program it has in memory, because it can always read it back from the original executable.

[0] https://man7.org/linux/man-pages/man2/mlock.2.html

[1] https://ftp.gnu.org/old-gnu/Manuals/glibc-2.2.3/html_chapter...

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

#29

Post by xena »

whalesalad wrote: post #25

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

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

#30

Post by Jabbles »

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 server that had the site data compiled into ram."

Post reply on HN