Convert this one to fcgi, and it will get as fast as any other solution. In fcgi mode it runs as a service listening to a socket and reads and sends response over it while never terminating.
Even php running on fcgi mode is far faster than the old styled mod_php.
If you don't have enough ram for it to be in the disk cache, chances are your fcgi daemon is going to get swapped out too.
Now if your program insists on taking forever to start up, that's something that a long running daemon can help.
I haven't benchmarked, but I really don't see why php in fcgi mode would be much faster than mod_php. I've run both modes and they're both very fast. But then someone uses one of the popular frameworks and hello world takes 20-40ms, so it barely matters how you run php.
I have no figures on PHP, though if its execution model hasn’t changed from a decade ago most of this probably won’t affect it much because it effectively didn’t even persist modules. But I don’t know.
On my system in hosting (FreeBSD 13.2-RELEASE, 2x Xeon L5640), time perl -e '' with perl5-5.34.3_3 reports 3ms. On the same system time php -r '' takes 16 ms with php82-8.2.11 and a handful of libraries installed. By my own criteria, php as a cgi sucks; but I did say if your program takes too long to startup, run it as a daemon, which I think includes linking it in like mod_php or mod_perl.
On the topic of mod_php vs php_fcgi; with apache mod_php, an empty php file takes about 1.2 ms to serve, as measured by curl from when curl sends the GET request to when the content ends. I don't have a php fcgi server to try, but my recollection was something similar for minimum php output from lighttpd with php_fcgi on newer hardware.
Finally, of course, the runtime needs to start up again, compile/interpret the code, and, finally, execute it.
A binary will have the fastest startup. I'm sure there may be things that could be done. I don't know if perl mmap'd the .pl file as a readonly buffer, if each invocation would share that file (probably), and thus prevent that initial duplication. Don't know if any of the interpreters do this. Odds are this gain is lost in the whole startup of the interpreter anyways.
Also, using a binary, by a similar mechanic, lowers overall memory consumption. Have 100 connections all running the binary, they all share the code pages, and thus only "pay" for their individual data use. Share 100 connections with an interpreter, and they each pay their own cost for the entire program file plus any runtime data. Again, not so much a problem today with our ample memory resources, and mmap the source may remedy this, but this actually was an issue back in the day.
Node.js is firmly designed for daemon operation, where having a high cost of instantiating a module, something that you only do at startup, is fine, if it means you later get better throughput because you’ve done JIT compilation or whatever. (It may also just be that Node.js is unnecessarily slow at these things because no one’s cared enough. But module loading being slow is reasonably well-known in the ecosystem at large so I doubt it’s particularly that.)
PHP might have lower engine startup costs because of its history of CGI usage, and lower code loading costs because of its start-from-scratch-for-each-request model—but both are probably at a later runtime cost.
Perl might have lower engine startup costs because it’s tended to be in a similar basket to PHP, plus more general scripting use, where you just want to get through things quickly: faster for one-offs, slower for repeated things. And my understanding of Perl is that it’s somewhat closer to just being an interpreter (which is excellent for latency but terrible for throughput) than are the other languages we’re discussing.
$ hyperfine --shell=none "node -e ''" "python -c pass" "perl -e ''" "php -r ''" "bash -c ''" "echo"
Benchmark 1: node -e ''
Time (mean ± σ): 87.3 ms ± 8.0 ms [User: 69.8 ms, System: 18.4 ms]
Range (min … max): 77.9 ms … 111.1 ms 31 runs
Benchmark 2: python -c pass
Time (mean ± σ): 24.4 ms ± 5.6 ms [User: 17.5 ms, System: 6.7 ms]
Range (min … max): 15.8 ms … 31.3 ms 97 runs
Benchmark 3: perl -e ''
Time (mean ± σ): 2.8 ms ± 0.6 ms [User: 0.9 ms, System: 1.8 ms]
Range (min … max): 1.7 ms … 3.9 ms 863 runs
Benchmark 4: php -r ''
Time (mean ± σ): 19.3 ms ± 4.2 ms [User: 8.9 ms, System: 10.0 ms]
Range (min … max): 12.1 ms … 24.8 ms 241 runs
Benchmark 5: bash -c ''
Time (mean ± σ): 4.9 ms ± 0.8 ms [User: 2.8 ms, System: 1.8 ms]
Range (min … max): 2.6 ms … 6.4 ms 552 runs
Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet system without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.
Benchmark 6: echo
Time (mean ± σ): 1.2 ms ± 0.3 ms [User: 0.7 ms, System: 0.3 ms]
Range (min … max): 0.8 ms … 2.1 ms 2237 runs
Summary
echo ran
2.41 ± 0.89 times faster than perl -e ''
4.17 ± 1.39 times faster than bash -c ''
16.37 ± 5.91 times faster than php -r ''
20.74 ± 7.64 times faster than python -c pass
74.21 ± 22.49 times faster than node -e ''
If you trade low/no build time for high startup latency, by all means stay clear of CGI at all cost.
I've built fast CGI based systems, but not recently, because I prefer the convenience of an interpreted language, so I am not arguing you should prefer CGI.
Just that comparing a design pattern that is a consequence of not using CGI is a poor measure of CGI. If you were to seriously want to use CGIs, you wouldn't use runtimes that slow to start, or spread everything over hundreds of files, at least without a build step.
A real weakness cgi has is that if your application involves a lot of in-memory configuration that has a terrible impact on startup time even if it has an excellent effect on execution time.
Typo?
fastcgi c/c++ server development was essentially stopped many years ago, would love to see a c version that I can use for embedded boards, though cgi does the job 90% of the time just fine.
https://svn.apache.org/viewvc/httpd/httpd/trunk/
It’s a fork of what you linked (and was more popular afaik back when fastcgi was state of the art, and apache was the undisputed champion of web servers).
These days, nginx has more market share than apache, and its fastcgi module is one of the more recently updated ones in its source tree (5 months vs multiple years):
https://github.com/nginx/nginx/tree/master/src/http/modules
If I was going to build an embedded web server, I’d start with nostd rust, probably with though axum + tokio, since thats already memory safe-ish.
If I needed fastcgi for some reason (dynamically loadable endpoints, or os-level isolation), there are at least four implementations of fastcgi for it. No idea if any are decent though.
Maybe not by much though.
https://www.netcraft.com/blog/december-2023-web-server-surve...
What's the point of using this over serving HTTP directly? The whole point of CGI was providing an easy to implement interface to proper HTTP servers, but FastCGI is such as step up in complexity compared to CGI that you're going to need a library anyway.
Maybe FastCGI made sense back when companies tried to convince us we needed their heavy-duty software to handle any HTTP traffic at all, but now HTTP libraries and reverse proxies are dime a dozen.
* I agree that you often will want a server such as Caddy/nginx/Apache httpd to be the Internet-facing http server. They give you a lot of nice things like DoS resistance, logging, robust TLS implementations, and dispatch to all the various applications you might be running.
* But you need some protocol between that proxy and your application. Like debugnik, I'd prefer to just use HTTP as that protocol rather than something else like FastCGI. I already have to be familiar with HTTP/1.1 in the sense that I both actually know the wire format by heart and know of a huge variety of tools that can directly speak it. So I'd rather just have my application speak HTTP over a Unix or IP socket that my frontend webserver proxies to. "Each HTTP-serving lib is another liability" is at least as true for "each FastCGI-serving lib" given that the FastCGI libs will be obscure (less well-tested and maintained) and (due to poorer familiarity/tooling) harder to debug.
True-ish, but complicated a bit because (as far as I can tell) the FastCGI spec is tiny compared to HTTP... even just HTTP 1.1, let alone 2 and (yikes) 3.
That's true-ish also. For this back leg, it's fine to only support HTTP/1.1; the frontend server can handle translation from HTTP/{2,3} as necessary. And the HTTP/1.1 spec defines a lot of stuff like the syntax/semantics of the headers and semantics of different request methods that the FastCGI spec doesn't address. It's still probably true that the HTTP/1.1 wire format a bit more complex than FastCGI, but it's much closer than it might first appear. On balance I'd still take HTTP any day.
[EDIT] And, as noted in my response to the other reply here, the size of the FastCGI spec, and the size of implementations, are far smaller than HTTP, which is nice.
If it's then also prepared properly, e.g statically linked position independent code, you won't even have relocation overhead and the only thing you "pay" is the process creation overhead, which hasn't been a major issue on at least Linux for a couple of decades at least.
Whether the difference will matter really depends on your specific runtime. With an interpreter, startup can easily bite you hard, sure.
PHP is a bad example for that reason - the moment you need a bunch of extra syscalls on startup, the context switch latency alone will kill performance vs. what you can achieve.
I have an internal app that runs as a CGI but is written in a compiled language. It averages 100ms response times, mostly due to database queries.
I wouldn’t write a major app using cgi but for small sites and internal services it’s fine