4 ms·

CGI is slow [ spawns an OS process for every request ]. But FCGI is as fast as any other solution, like compiling the whole app in a single binary and running i

CGI is slow [ spawns an OS process for every request ]. But FCGI is as fast as any other solution, like compiling the whole app in a single binary and running it as a HTTP server.

sgbeal 4y ago
> CGI is slow .... CGI is _computationally_ slow, but in practice it's faster than it needs to be for most sites. Some examples of CGI-powered sites i'm aware of include: - https://sqlite.org/forum https://sqlite.org/forum - https://sqlite.org/wasm https://sqlite.org/wasm (same domain, different sub-site) - https://fossil-scm.org/home https://fossil-scm.org/home - https://fossil-scm.org/forum https://fossil-scm.org/forum (same domain, separate sub-site) - https://fossil.wanderinghorse.net https://fossil.wanderinghorse.net All CGI, all the time, and _plenty_ performant for the purpose.
- yakubin 4y ago
  Add to it https://git.kernel.org/ https://git.kernel.org/
- WJW 4y ago
  Many people confuse "X is slower than Y" with "X is slow in some absolute sense". Starting a new process takes well under a millisecond on most modern machines, so that would be completely lost in the latency of most web requests. The real benefits of persistent processes are in getting to reuse database connections and the like.
  - ptx 4y ago
    > Starting a new process takes well under a millisecond on most modern machines But if that process is Python or Java it's going to be tens to hundreds of milliseconds before it's ready to serve the request.
    - alaaalawi 4y ago
      YMMV, but thats why i love Forth. it compiles the full app (not interpret) in ms. some think its dead or only for the embedded, but for me and my projects its a deadly combination + ultra fun.
hawski 4y ago
I did a simple benchmark to test how fast forking is: https://gist.github.com/hadrianw/ad07a76f338f09565703ae6ea35993c8 https://gist.github.com/hadrianw/ad07a76f338f09565703ae6ea35... It tested in a loop fork/exec and vfork/exec for a dynamic binary and for a static binary with musl. On an Intel Core i5 6600k: regular: fork 13179 ms / 100000 = 131 µs, 7587 per sec vfork 14423 ms / 100000 = 144 µs, 6933 per sec static: fork 3173 ms / 100000 = 31 µs, 31515 per sec vfork 3833 ms / 100000 = 38 µs, 26089 per sec
- thehappypm 4y ago
  Wow, I read this as ms at first, microseconds is really phenomenal
- _flux 4y ago
  Yeah, I don't think the speed performance of FCGI vs CGI is really about spawning in 2023: the benefit lies in the fact that the app can keep state and resources between requests. In particular, it can maintain a database connection all the time (with a retry logic for the case when it gets disconnected). However, perhaps 15+ years ago I converted an application to an Apache module from a cgi-bin binary and the performance benefit was immense in an embedded Linux device. We certainly were not talking even about tens requests per second in the CGI version.
  - 10000truths 4y ago
    > the benefit lies in the fact that the app can keep state and resources between requests. You can share state between processes using temporary files/shared memory. Like CGI itself, it doesn’t scale as well, but it’s not even a blip on resource usage unless you’re dealing with thousands of requests per second. > In particular, it can maintain a database connection all the time (with a retry logic for the case when it gets disconnected). You can run a daemon that performs the connection pooling for you, and have each request connect to the daemon instead.
    - Kwpolska 4y ago
      Temporary files/shared memory won’t solve the cost of starting up a Python interpreter or a JVM or whatever and importing all your code with its dependencies. As for the connection pooling daemon, you still need to connect to it. It might be faster than talking to the database directly on a different server, but no new connection still beats new local connection.
aliqot 4y ago
> like compiling the whole app in a single binary and running it as a HTTP server. Not so uncommon these days tbh
ilyt 4y ago
Probably still less slowdown than some heavy framework
icedchai 4y ago
Spawning a process is not that slow on modern hardware. CGI is considered slow, because back in the 90's, everything was slow and resource constrained. Slow processors, limited RAM, slow disks for swap, slow internet connections... I remember developing Perl CGI scripts on a Sparc 10 with 32 megs of RAM connected to a T1 that was nearly always maxed out. On a related note, "modern" cloud-based application development strategies (like AWS Lambda) seem no faster than CGI. We've come full circle. Though now things are more distributed, of course.
- elwebmaster 4y ago
  More distributed so they break in random places at random times. They never go fully down and they never fully work…

CGI is slow [ spawns an OS process for every request ]. But FCGI is as fast as any other solution, like compiling the whole app in a single binary and running it as a HTTP server.

sgbeal 4y ago

> CGI is slow .... CGI is _computationally_ slow, but in practice it's faster than it needs to be for most sites. Some examples of CGI-powered sites i'm aware of include: - https://sqlite.org/forum https://sqlite.org/forum - https://sqlite.org/wasm https://sqlite.org/wasm (same domain, different sub-site) - https://fossil-scm.org/home https://fossil-scm.org/home - https://fossil-scm.org/forum https://fossil-scm.org/forum (same domain, separate sub-site) - https://fossil.wanderinghorse.net https://fossil.wanderinghorse.net All CGI, all the time, and _plenty_ performant for the purpose.

yakubin 4y ago
Add to it https://git.kernel.org/ https://git.kernel.org/
WJW 4y ago
Many people confuse "X is slower than Y" with "X is slow in some absolute sense". Starting a new process takes well under a millisecond on most modern machines, so that would be completely lost in the latency of most web requests. The real benefits of persistent processes are in getting to reuse database connections and the like.
- ptx 4y ago
  > Starting a new process takes well under a millisecond on most modern machines But if that process is Python or Java it's going to be tens to hundreds of milliseconds before it's ready to serve the request.
  - alaaalawi 4y ago
    YMMV, but thats why i love Forth. it compiles the full app (not interpret) in ms. some think its dead or only for the embedded, but for me and my projects its a deadly combination + ultra fun.

hawski 4y ago

I did a simple benchmark to test how fast forking is: https://gist.github.com/hadrianw/ad07a76f338f09565703ae6ea35993c8 https://gist.github.com/hadrianw/ad07a76f338f09565703ae6ea35... It tested in a loop fork/exec and vfork/exec for a dynamic binary and for a static binary with musl. On an Intel Core i5 6600k: regular: fork 13179 ms / 100000 = 131 µs, 7587 per sec vfork 14423 ms / 100000 = 144 µs, 6933 per sec static: fork 3173 ms / 100000 = 31 µs, 31515 per sec vfork 3833 ms / 100000 = 38 µs, 26089 per sec

thehappypm 4y ago
Wow, I read this as ms at first, microseconds is really phenomenal
_flux 4y ago
Yeah, I don't think the speed performance of FCGI vs CGI is really about spawning in 2023: the benefit lies in the fact that the app can keep state and resources between requests. In particular, it can maintain a database connection all the time (with a retry logic for the case when it gets disconnected). However, perhaps 15+ years ago I converted an application to an Apache module from a cgi-bin binary and the performance benefit was immense in an embedded Linux device. We certainly were not talking even about tens requests per second in the CGI version.
- 10000truths 4y ago
  > the benefit lies in the fact that the app can keep state and resources between requests. You can share state between processes using temporary files/shared memory. Like CGI itself, it doesn’t scale as well, but it’s not even a blip on resource usage unless you’re dealing with thousands of requests per second. > In particular, it can maintain a database connection all the time (with a retry logic for the case when it gets disconnected). You can run a daemon that performs the connection pooling for you, and have each request connect to the daemon instead.
  - Kwpolska 4y ago
    Temporary files/shared memory won’t solve the cost of starting up a Python interpreter or a JVM or whatever and importing all your code with its dependencies. As for the connection pooling daemon, you still need to connect to it. It might be faster than talking to the database directly on a different server, but no new connection still beats new local connection.

aliqot 4y ago

> like compiling the whole app in a single binary and running it as a HTTP server. Not so uncommon these days tbh

ilyt 4y ago

Probably still less slowdown than some heavy framework

icedchai 4y ago

Spawning a process is not that slow on modern hardware. CGI is considered slow, because back in the 90's, everything was slow and resource constrained. Slow processors, limited RAM, slow disks for swap, slow internet connections... I remember developing Perl CGI scripts on a Sparc 10 with 32 megs of RAM connected to a T1 that was nearly always maxed out. On a related note, "modern" cloud-based application development strategies (like AWS Lambda) seem no faster than CGI. We've come full circle. Though now things are more distributed, of course.

elwebmaster 4y ago
More distributed so they break in random places at random times. They never go fully down and they never fully work…