It is interesting concept for a blog post but ruined by very inefficient implementation.

I would expect orders of magnitude more work done on ~20W.

Also parsing a compressed 10MB JSON seems like an unusual request. It would maybe be more fun to put a Hello World or Pet Store and get some numbers that will be more relatable to a regular developer.

I mean, everyone's gotta start somewhere. I'll give the author props for coming up with an idea for an experiment, documenting it, and sharing their results. Not a whole lot of people do that out in the open, and it's great to see a bunch of responses with suggestions for further improvements. :)

You must have a very low level of expectations of your fellow HN reader if you think that anything above a Hello World tutorial is relatable to a regular developer.

How frequently do you test a new web framework with "10MB compressed JSONs"?

On the other hand you can find a lot of benchmarks that use basically Hello World just to test your request response or some rather small request/response sizes, because this is what most applications actually do. You can add a simple database query to it for more realistic load.

So, yes, this is more relatable to me as a backend developer because I can compare results more easily.

I see the issue with your premise. I don't test web frameworks. I do real work <ducks>

I very much routinely look at large data sets. They just happen to be wrapped up in a different container than ZIP. Typically, they are delivered in MOV, MP4, WAV, etc. I look at a 10MB file and try to remember the last time I counted that small.

But you do do a minimal HTTP-free baseline benchmark for better insight of your comparison purpose of all things above?, no?

The test is for a web server, so you're optimizing for throughput on limited power, a static site would seem to be the best test.

If you want to test CPU load, the author should have tried Prime95 or some other similar test.

Years ago someone made a potato-powered web server. It was an 8-bit microcontroller with a custom TCP/IP stack, if I remember correctly.

Intentionally inefficient. I’ve seen a number of my customers doing this pattern, working with ~10 meg JSON for the model layer.

Inefficient but not unrealistic outside of FAANG.