Hacker News Reader

The important metrics is peak requests per second. 14M / day sounds impressive, but it’s only a sustained 160 per second which literally any language and framework can handle on the lowest end hardware.

View on HN

Sure, peaks are much higher. But a good part of it is reverse proxying with in-memory caching and locking, which I've implemented in several stacks over the years, and many struggle with it (I have been paid to do comprehensive benchmarks on the topic). On the BEAM it's a non-event.

Seriously

Even pre ai you could toss together a decent cache in about a minute using ets or similar, and faster with a solution like cachex (which was basically what you'd build yourself but packaged into a neat little bundle)

I wrote it pre-AI, using cachex!

It is open-source:

https://github.com/etalab/transport-site/tree/master/apps/tr...

Only if users are nice and spread the load evenly over the day, but they are never so considerate.

Sure, that's why I highlighted peaks as a more important metric than average. Even an order of magnitude higher peaks over the average is still fairly trivial, compared to where BEAM shines. Maintaining hundreds of thousands of concurrent long-lived connections per server is what it excels at, but also not something that's relevant to 99% of web apps out there.

Reply on news.ycombinator.com