Serving a high-performance blog solely from memory, using Rust
1–10 of 143 posts
Re: Serving a high-performance blog solely from memory, using Rust
#2How 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?
Re: Serving a high-performance blog solely from memory, using Rust
#3Without reading: why do Rust folks think it's better if they memorise a website and serve it, instead of using a computer?
Re: Serving a high-performance blog solely from memory, using Rust
#4How 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?
With a static page generator, the file is still on disk. You've got a read cache for the disk, but that's not entirely reliable.
Re: Serving a high-performance blog solely from memory, using Rust
#5How 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?
On the one hand, sure, you can probably squeeze some cycle or two out of buffering everything in memory. Even though your disk read is a memory read in all likelihood given how filesystem caching works, it's still an IO call, which isn't free.
Keeping everything in user space buffers might just be faster.
On the other hand, you're sending that sucker over network, and what you save doing this is most likely best counted in microseconds/request. It's piss in the ocean compared to the delay introduced even over a local network.
Re: Serving a high-performance blog solely from memory, using Rust
#6Website title: My Blog is Hilariously Overengineered to the Point People Think it's a Static Site
Seeing the initial comments here I think it would be better to go with the original title.
Re: Serving a high-performance blog solely from memory, using Rust
#7Without reading: why do Rust folks think it's better if they memorise a website and serve it, instead of using a computer?
The borrow checker is much less strict if the data only lives inside your skull. Much harder to mutably borrow.
Re: Serving a high-performance blog solely from memory, using Rust
#8How 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?
With a static page generator, the file is still on disk. You've got a read cache for the disk, but that's not entirely reliable.
Just like the Rust executable is still on disk. Sure, if it is running, it is memory mapped, but it can still be paged out. This is not theoretical. In practice, upon request, the probability of finding the static page in cache should be similar to the probability of the executable not being paged out. (That's true as long as the actual data is the same, and the differing factors, like the size of the web server executable, are small compared to the amount of free memory.)
Re: Serving a high-performance blog solely from memory, using Rust
#9Earlier quoted context omitted.
With a static page generator, the file is still on disk. You've got a read cache for the disk, but that's not entirely reliable.
Just like the Rust executable is still on disk. Sure, if it is running, it is memory mapped, but it can still be paged out. This is not theoretical. In practice, upon request, the probability of finding the static page in cache should be similar to the probability of the executable not being paged out. (That's true as long as the actual data is the same, and the differing factors, like the size of the web server exec…
Author here. That server doesn't have swap enabled. It can't be paged out.
Re: Serving a high-performance blog solely from memory, using Rust
#10How 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 was thinking the same. They said a Go precompiled version was faster, but was 200MB. Which I don't understand.
200MB of pages and assets, sure. Code? No. If you compile it into the binary then the storage is no worse than having a small binary and all the resources separate.
Taking a statically generated site and returning the raw bytes is 100% faster. The author said so themselves.