Everyone thought it was amazing even though it was just a dumb http server returning pages[req.path] :-) Latency was under 10ms which was pretty amazing for a 2012 KVM VPS.
Serving a high-performance blog solely from memory, using Rust
71–80 of 143 posts
Re: Serving a high-performance blog solely from memory, using Rust
#72How 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 coun…
I wonder if io_uring could be used to issue a single syscall that would read data from disk (actually using page cache) and send it on the network.
Of course, you could use DPDK or similar technologies to do the opposite - read the data from disk once and keep it in user-space buffers, then write it directly to NIC memory without another syscall. That should still theoretically be faster, since there would be 0 syscalls per request, where the other approach would require 1 per request.
Re: Serving a high-performance blog solely from memory, using Rust
#73Re: Serving a high-performance blog solely from memory, using Rust
#74Earlier quoted context omitted.
The main thing the CDN provided was nodes on basically every continent that kept the site in cache. Without those servers on every continent keeping the site in cache, it takes longer to get to the netherlands to get the site loaded. The speed of light is only so fast.
> The speed of light is only so fast. Is the Internet not connected internationally (US -> Europe for example) via cables underneath the ocean? Speed of light would be satellite, light? Not electric current? Or is electricity flowing through a wire also "speed of light"?
Re: Serving a high-performance blog solely from memory, using Rust
#75The tech is cool, but some of the language is so cringy. For example, the statement "websites are social constructs" makes zero sense. You could say that websites are material objects of a symbolic network of computer languages, like physical paper money is a material, fetishized object of the social construct of money. Websites themselves are not constructed socially. Maybe the author means how websites are perceive…
Re: Serving a high-performance blog solely from memory, using Rust
#76You don't need Rust for this -- you can do the same in Go, Node, etc. In 2012 my cheap VPS had a crappy HDD share but fairly acceptable memory, so I rendered the Markdown files and stored them in a little structure, returning them directly from memory. Everyone thought it was amazing even though it was just a dumb http server returning pages[req.path] :-) Latency was under 10ms which was pretty amazing for a 2012 KVM…
> And when I say fast, I mean that I have tried so hard to find some static file server that could beat what my site does. I tried really hard. 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. None of them were faster, save the precompiled Go binary (which was like 200 MB and not viable for my needs). It was hilarious. I have accidentally created something so efficient that it's hard to really express how fast it is.
Re: Serving a high-performance blog solely from memory, using Rust
#77Earlier quoted context omitted.
> see if you find any "forbidden thoughts" As always, Venn diagram of "people with extremely pointless gripes about the Rust language" and "people who compare the slightest criticism to being accused of thoughtcrime" is a circle. That's not to say everyone who dislikes Rust is like this. I have plenty of gripes about Rust. Just the people who say things like "if you use a refcount and make a cycle, you can leak memor…
Some seem to interpret the very existence of other people's ideas and especially what they perceive as an emerging consensus as a threat to their autonomy? I don't understand but I do observe it. I feel like what people actually take issue with is the existence of Rust and with people talking about it, and so they complain about how often it's on the front page, or they'll complain that it's in the title of the post,…
Re: Serving a high-performance blog solely from memory, using Rust
#78There may be further opportunities for improvement. Chrome and Curl both report it takes about 1100ms to load the linked page's HTML, split about 50/50 between establishing a connection and fetching content. I'm not sure how the implementation works internally but that seems like a long time for a site served from memory and aiming to be "high-performance". The images bring the total time up to around 5.7s. As a poin…
Re: Serving a high-performance blog solely from memory, using Rust
#79How 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?
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 trying a read with RWF_NOWAIT and only falling back to a thread pool if necessary.
On the other hand rendering a template on each request also requires CPU, which might be either more or less expensive than doing a syscall.
All in all the efficiency differences are likely negligible unless you run a CDN which does thousands of requests per seconnd.
In terms of throughput to the end user it will make zero measurable difference unless the box ran out of CPU.
Re: Serving a high-performance blog solely from memory, using Rust
#80Earlier quoted context omitted.
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 coun…
> 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. I wonder if io_uring could be used to issue a single syscall that would read data from disk (actually using page cache) and send it on the network. Of course, you could use DPDK or similar technologies to do the opposite - read the data from disk once and keep it in user-space b…
Only if you don't care about HTTP/2 and TLS. And if you don't care about those, you can as well do sendfile() from a thread.