Live data from Hacker News

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

xeiaso.net

41–50 of 143 posts

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

#41
After 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

#42

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.

With a bit of dedication you could probably get that put together with https://github.com/auxoncorp/ferros using Rust & seL4.

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

#43

After 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.

Ripping out cloudflare made the metrics slower. I wrote this post before I ripped out cloudflare and it was accurate at the time of writing. It will be better once I can re-engineer things to be anycasted.

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

#44

Quoted 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 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

#45
post #20

Earlier 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…

> Does Apache/Nginx/IIS load static files in memory ahead of time?

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

#46
post #44

Quoted 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…

No post body was provided.

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

#47

Earlier 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.

Just like on most low end embedded systems. Bare metal rules there.

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

#48
post #44

Earlier 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.

> 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 memory, oh noez".

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

#49
post #14

There 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.

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.

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

#50
post #49
post #14

Earlier 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.

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.
Post reply on HN