4 ms·

The FastCGI approach is not a million miles away from how (at least some) serverless services work AFAIK. > do have an issue with programs that have a lot of s

• 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 ago
    I 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.