4 ms·
The cgi model(also inetd) starts a new process on every single request. If you wrote your service in C like god intended(sarcasm) this is not a problem, unix s
by somat 2y ago
The cgi model(also inetd) starts a new process on every single request.
If you wrote your service in C like god intended(sarcasm) this is not a problem, unix systems are traditionally by design very good at starting processes.
However python(my favorite language for what it's worth) has a lot of baggage it needs to sort out when it starts. so python specifically and any interpreted language that takes more than a few milliseconds to start in general starts to suffer under heavy loads in the one process per request model.
Thus the motivation to make it one process for many requests.
- rakoo 2y ago> starts to suffer under heavy loads The figures from 1990 are not the same as the figures from 2024. "heavy" here is so high it is not a realistic problem for 80% of sites.
- linschn 2y agoI would be honestly surprised if any listen server ever experience heavy loads ;) this is more targeted at smolweb-scale hosts. On current hardware it can serve up to a few hundreds requests/s without too much trouble. There's also the trick of pre starting a pool of processes beforehand and handing the data to them when it comes. It is not implemented in listen yet, but would not be too hard to do.
- aidenn0 2y ago> I would be honestly surprised if any listen server ever experience heavy loads ;) this is more targeted at smolweb-scale hosts. This was true of cgi scripts written in perl too, until they made the frontpage of slashdot.