Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

xeiaso.net

Post reply on HN
Print view View original

91–100 of 143 posts

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

#91

Post by pornel »

llllllllllll9 wrote: post #38
mejutoco wrote: post #34

Earlier quoted context omitted.

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.

be careful and do your research. 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 .

It's not anytime. It's limited to recursive types with interior mutability. These two conditions are specific to mutable graphs, not just any shared ownership. There are plenty of uses of Rc that cannot possibly cause a cycle.

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

#92

Post by hinkley »

filleokus wrote: post #17
trh0awayman wrote: post #13

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.

I guess Unikraft is that, kinda? https://github.com/unikraft/app-nginx

Well, that shows some promising numbers, but it's still a unikernel rather than an embedded OS which is I think what OP is asking for.

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

#93

Post by xani_ »

19h wrote: post #71

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

I did that in Go although it was "only" caching the markdown rendering - the page templates were written in Go (via some lib that gave tools to make that mangeable) and compiled with the app so the whole template building was blazingly fast.

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

#94

Post by xani_ »

jmillikin wrote: post #15
xena wrote: post #9

Earlier quoted context omitted.

Author here. That server doesn't have swap enabled. It can't be paged out.

If the executable is on disk, it can be paged out unless you've used mlock() to tell the kernel to keep it resident.

If swap is off there is nowhere to page it out

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

#95

Post by hinkley »

marcosdumay wrote: post #45
dec0dedab0de wrote: post #35

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

> Linux loads them on the first usage.

Yes, but.

The problem with OS file caches has ever been that people look at a box, see that the programs aren't consuming all of the available memory, and argue that they should be able to cram more shit on the box because it's 'underutilized'.

There are very reasonable and sane system architectures that let the OS handle caching, but you need a way to defend against these sorts of situations.

The performance falloff for this failure mode is exponential, so people try it a few times, and not getting any negative feedback, they add it to their toolbox only to get lectured months later once the bad behavior has not only become standard for them but also spread to other people.

It almost begs for a different system call that can earmark the memory usage by the app in a way that's easier for people to see.

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

#96

Post by xani_ »

Philip-J-Fry wrote: post #10
Thaxll wrote: post #2

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

Technically with go:embed you could trivially make a blog server that is just a 200MB binary with all of it embedded.

If you did it that way, now all your content is basically mmaped into the memory which means (probably) less syscalls.

Soo it might've shaved half a microsecond maybe ?

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

#97

Post by hinkley »

Kansaete wrote: post #88
xena wrote: post #60

Earlier quoted context omitted.

Author here. I don't identify as male. It would be nice if you could update your comment to not make a factual error when referring to me. Please use https://pronoun.is/they . Thanks!

Quoted post unavailable.

Methinks someone lacks the courage of their convictions.

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

#98

Post by xani_ »

dawnbreez wrote: post #84
greenhearth wrote: post #58

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

A website is a social construct because it can only function by the agreement of everyone involved (i.e., we all agree on how to parse HTML). The individual site may be constructed individually ( maybe ) but it can only work if the society of people-who-use-the-internet all agree to follow a series of conventions about how websites work; you can't start using \ instead of \ and expect everything to work as normal, be…

Sure but that's as useful as saying shit is social construct because we as humans decided to name it that. Technically true, practically it's vapid useless speech that doesn't bring anything useful to the discussion aside from person using the term feeling smart

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

#100

Post by joshspankit »

xena wrote: post #65
xena wrote: post #55

Earlier quoted context omitted.

The blog itself is fast. The internet is the slow part.

I thought of a better way to phrase it. The website itself is fast, but the process of you observing the website is slow because of limitations of the speed of light (or other interconnects the internet uses to get your traffic to Helsinki).

I think what you’re saying is that if OP were to test your site from Helsinki they would see the server speed you’re talking about. Is that right?
Post reply on HN