If I remember correctly, Arc is an ongoing experiment in language design, not high-performance implementation.

And it's running on top of PLT Scheme, which adds another layer of interpretation.

And it's running as a single process on a single server without a database storing everything on the file system. That it's doing the traffic it is I find quite impressive.

In 2 GB of memory.

You know I'd love to see a writeup of the issues and challenges you've faced with this persistence strategy as the site grew. You know, more details of what you decided to lazy load, why, and how, and the impact it had.

Technically speaking, I find hacker news persistent strategy one of the most interesting things about the implementation.

I use a similar strategy for my blog and just playing with larger datasets I've certainly run into hard limits on what seems to be acceptable.

Upstream. Both ways. In the snow.

Extrapolating from the memory-growth graph, how much time would a 16GB ram machine buy you?

I'd have thought that most of HN's traffic is on the front page, and it's associated comments. I could well be wrong - But given this I'd have thought 2GB was plenty, and wasn't the bottleneck.

Ok maybe not: http://news.ycombinator.com/item?id=512801

Are there any articles on the "HN storing everything on the file system"?

I am quite interested in the architecture, because I found this approach nice for some sites I was building. They were not very large though.

If you're keen, you can get the source code and take a look: http://www.arclanguage.com/install

File system stores aren't that uncommon (aside from the VSAM days, even in RDBMS times+) - it's a common approach for Wiki implementations too.

Also, unless your DB tables are in-memory tables, you are using a very fancy interface to a file system store (that is usually in a nontrivial format.)

> without a database

Why?

I can understand not using a database if this was improving the performance.

PLT Scheme is not "interpreting" code. More than that, Arc adds a bunch of huge overheads that could make things substantially faster. I had some patches lying around that made things around 4-5 times faster (including the news server).

but it's calling all those ar_funcall2 or whatever ... not that much indirection really.

33k users per day is piddly little bits. I think that a platform change is called for, the current recipe is clearly no longer up to the task. Which is a pity, because the lisp code really is quite elegant. It's just that the web and high performance and lisp are not usually used in a single sentence (other than this one...).