edit: web.dev measure gave this blog post url a performance score of 30/100 which is quite poor.
Serving a high-performance blog solely from memory, using Rust
41–50 of 143 posts
Re: Serving a high-performance blog solely from memory, using Rust
#42I 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.
Re: Serving a high-performance blog solely from memory, using Rust
#43After going to the end of a long post, I'm disappointed to not find any latency or throughput efficiency metrics. Author seems to claim he has a very popular high-traffic blog and it is super fast, faster than all the popular web servers serving static pages. Where's the performance data to prove this? edit: web.dev measure gave this blog post url a performance score of 30/100 which is quite poor.
Re: Serving a high-performance blog solely from memory, using Rust
#44Quoted post unavailable.
It suggests to me you know as well as we do that the downvotes were about snarkily expressing your views while making mistakes that might suggest you aren't all that familiar with rust in the first place, and not that you're expressing "forbidden thoughts."
Re: Serving a high-performance blog solely from memory, using Rust
#45Earlier quoted context omitted.
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 co…
Linux loads them on the first usage. If you have enough memory, they'll just stay there. It doesn't that much memory, most sites are pretty small.
But the article's way doe use less memory, less system calls, and is completely optimized for that one site only. So yeah, it will surely be faster. Besides, his site appears to not be static.
Re: Serving a high-performance blog solely from memory, using Rust
#46Quoted post unavailable.
It's pretty bad faith to post an inflammatory comment, initially with several errors like referring to the Ref stuct instead of Rc , add edits to complain about downvotes, and then steadily edit it to be more correct and reasonable while leaving in the complaints about downvotes. Leaving the impression that it was the current iteration that attracted the downvotes because "the truth hurts". It suggests to me you know…
Re: Serving a high-performance blog solely from memory, using Rust
#47Earlier quoted context omitted.
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
#48Earlier quoted context omitted.
It's pretty bad faith to post an inflammatory comment, initially with several errors like referring to the Ref stuct instead of Rc , add edits to complain about downvotes, and then steadily edit it to be more correct and reasonable while leaving in the complaints about downvotes. Leaving the impression that it was the current iteration that attracted the downvotes because "the truth hurts". It suggests to me you know…
Quoted post unavailable.
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 memory, oh noez".
Re: Serving a high-performance blog solely from memory, using Rust
#49There 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…
Author here. I wrote that post before I axed the CDN for my blog site itself. It was true at the time of writing, but it is not true anymore because I need to redo the CDN for the blog itself. All the images are CDNed with XeDN though.
You removed the CDN and the site got slower?
How do you know your site was the one that was fast or just the CDN? IE, the CDN should have added a lot of extra hops and made things slower.
To me, this implies the rust code is very poor at opening and closing connections, so the CDNs keep alive is pasting over that issue.
Re: Serving a high-performance blog solely from memory, using Rust
#50Earlier quoted context omitted.
Author here. I wrote that post before I axed the CDN for my blog site itself. It was true at the time of writing, but it is not true anymore because I need to redo the CDN for the blog itself. All the images are CDNed with XeDN though.
I'm trying to parse what you are saying here. You removed the CDN and the site got slower? How do you know your site was the one that was fast or just the CDN? IE, the CDN should have added a lot of extra hops and made things slower. To me, this implies the rust code is very poor at opening and closing connections, so the CDNs keep alive is pasting over that issue.