Serving a high-performance blog solely from memory, using Rust
31–40 of 143 posts
Re: Serving a high-performance blog solely from memory, using Rust
#32Earlier 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?
Re: Serving a high-performance blog solely from memory, using Rust
#33Earlier 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.
Re: Serving a high-performance blog solely from memory, using Rust
#34Quoted post unavailable.
Re: Serving a high-performance blog solely from memory, using Rust
#35Earlier 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.
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
#36It 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…
Re: Serving a high-performance blog solely from memory, using Rust
#37Re: Serving a high-performance blog solely from memory, using Rust
#38Quoted 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.
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.
Re: Serving a high-performance blog solely from memory, using Rust
#39Quoted post unavailable.
planning on it :)