3 ms·

Inetd style services are great, but do have an issue with programs that have a lot of startup overhead (e.g. things written in Python). I always thought the Fa

Inetd style services are great, but do have an issue with programs that have a lot of startup overhead (e.g. things written in Python). I always thought the FastCGI approach was a neat one, with a defined protocol for what would otherwise start a new process, and the managing daemon can choose if/when to start and stop the process. It certainly makes the listening daemon significantly more complicated, and the actual launched program slightly more complicated, but IMO there are real benefits there.

graemep 2y ago
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 startup overhead (e.g. things written in Python Unless you have a lot of startups its probably not a problem, I would have thought.
- 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.
somat 2y ago
That specific aspect(a persistent service worker) of fastcgi works well. but I have yet to find a compelling argument for fastcgi the protocol. let me explain. cgi as a protocol, really a calling convention for launching processes, make sense, it fits a specific niche in the ecosystem. fastcgi does not, fastcgi is a different incompatible http, that is, fastcgi does nothing that http does better. Did we all just collectively loose our ability to think critically, locked on to the fact that the common usage was that a http server launches a cgi process and when the time came to make that process it's own service, said we need cgi for services, creating fastcgi, forgetting that http already works just fine as a service? I am not really a back-end programmer, I am a sys-admin who sometimes makes web-based tooling. it is very possible there is a subtlety to this I missed. But I was a lot happier when I gave up on fastcgi and just made each service a http server with a reverse proxy in front to dispatch the requests.
- aidenn0 2y ago
  I agree completely that writing a FastCGI client is almost as hard as writing an HTTP client, so having a different protocol is gratuitous. See mongrel2 and pushpin as things that can connect to long-running services that speak HTTP over zmq. Neither will manage the worker processes the way Apache could with fastcgi though.

graemep 2y ago

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 startup overhead (e.g. things written in Python Unless you have a lot of startups its probably not a problem, I would have thought.

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.

somat 2y ago

That specific aspect(a persistent service worker) of fastcgi works well. but I have yet to find a compelling argument for fastcgi the protocol. let me explain. cgi as a protocol, really a calling convention for launching processes, make sense, it fits a specific niche in the ecosystem. fastcgi does not, fastcgi is a different incompatible http, that is, fastcgi does nothing that http does better. Did we all just collectively loose our ability to think critically, locked on to the fact that the common usage was that a http server launches a cgi process and when the time came to make that process it's own service, said we need cgi for services, creating fastcgi, forgetting that http already works just fine as a service? I am not really a back-end programmer, I am a sys-admin who sometimes makes web-based tooling. it is very possible there is a subtlety to this I missed. But I was a lot happier when I gave up on fastcgi and just made each service a http server with a reverse proxy in front to dispatch the requests.

aidenn0 2y ago
I agree completely that writing a FastCGI client is almost as hard as writing an HTTP client, so having a different protocol is gratuitous. See mongrel2 and pushpin as things that can connect to long-running services that speak HTTP over zmq. Neither will manage the worker processes the way Apache could with fastcgi though.