[rakoo]

> What do you think is the upper limit of requests per second, if your HTTP server does process-per-request ?

In the hundreds, which is absolutely enough for most use cases. If CGI is enough for sqlite.org displaying dynamic content (such as in https://www.sqlite.org/cgi/src/timeline), it is enough for 80% of websites. You are not bigger than sqlite.

> How do you think those metrics compare to other designs

The important question is not "is it better or worse than alternatives" but "is it enough for me". Yes, it is.

> Also, how does this design adapt to HTTP/2?

HTTP/2 doesn't change anything. Requests are on the same socket until the webserver, and the webserver forks a process for each request, multiplexes the responses and all is well.

[preseinger]

> The important question is not "is it better or worse than alternatives" but "is it enough for me". Yes, it is.

All good! But if you're OK with O(100) RPS out of a server, then I guess basically every possible option is on the table. I bet `nc` spawning background `bash` scripts to handle requests would get to 1k RPS, even! ;)

> HTTP/2 doesn't change anything.

I guess that would work, as long as the fronting server managed all of the connection management details, stream demuxing, etc. But I wonder how you'd do that in a single thread?