2400 rps on this hardware on hello world application - isn't it kinda bad?
And we trading performance for what exactly? Code certainly didn't become any simpler.
And we trading performance for what exactly? Code certainly didn't become any simpler.
Which is only a small proportion of sites out there.
I think the worst drama ever was a partial disk failure. Things kinda hobbled along for awhile before things actually started failing, and at that point things were getting corrupted. That poofed a weekend out of my life. Now I have better monitoring and alerting.
So you really do not have to be bothered by installation or anything of these lines. You install once and you are fine. You should check out the Wiki pages of Arch Linux, for example. It is pretty straightforward. As for upgrades, Arch Linux NEVER broke. Not on my servers, and not on my desktop.
That said, to each their own.
I will give you the benefit of the doubt that you are not regurgitating what other people have been saying (IMO wrongfully), which is: "Arch Linux for servers? Eww. Bleeding edge. Not suitable for servers.". All that said, please, do share. It will not negate those decades of no issues, however.
As I said, I maintain quite a lot of Arch Linux servers with loads of services without any issues, for decades.
Or if you don't want to pay for an 8/16 for the sort of throughput you can get on a VPS with half a core.
Sure, there are regressions that will make start-up overhead worse, but I mean, there will be pathological regressions in any configuration.
The thing limiting you to that number also isn't just the startup cost. If it was, you could just run more things in paralell. The startup cost kills your minimum latency, but the rps limit comes from some other resource running out; cpu, memory, context switching, waiting for other services that are in themselves limited, etc. If it's cpu, which is very likely for python, any little performance regression can melt down the service.
Life is so much easier if you just get a somewhat performant base to build on. You can get away with being less clever, and you can see mistakes as a tolerable bump in resource usage or response times rather than a fail-whale
In practise I'm not convinced -- but I would love to be. Reverse proxying a library-specific server or fiddling with FastCGI and alternatives always feels unnecessarily difficult to me.