|
|
|
|
|
by foota
1118 days ago
|
|
I think your comparison to CGI is unfair, since CGI in containers is quite different from "classic" CGI imo. Wikipedia describes CGI as "In computing, Common Gateway Interface (CGI) is an interface specification that enables web servers to execute an external program, typically to process user requests.[1] Such programs are often written in a scripting language and are commonly referred to as CGI scripts, but they may include compiled programs.[2] A typical use case occurs when a web user submits a web form on a web page that uses CGI. The form's data is sent to the web server within an HTTP request with a URL denoting a CGI script. The web server then launches the CGI script in a new computer process, passing the form data to it. The output of the CGI script, usually in the form of HTML, is returned by the script to the Web server, and the server relays it back to the browser as its response to the browser's request.[3]" Which bears little resemblance here imo. |
|
The typical way to deploy CGI during the '90s was to have a compiled program in C/C++, which would be executed once per request. There were entire frameworks built around this "process per request" model, with various optimizations like pre-warming (start the process, connect to db, wait for request on stdin) and variant protocols (SCGI).
Any time you have an execution model based on running a single address space per request, it's fundamentally CGI-ish. It doesn't have anything to do with the implementation language. The limitation of CGI is that state can't be persisted in-process between requests.
---
Going back to the thread, there's multiple aspects when thinking about the structure of a hosted service:
1. Whether state is shared between requests (CGI vs long-lived process).
2. Whether the binary is native code (x86/ARM/) or bytecode (WASM/JVM/).
3. Whether the binary is standalone or comes with additional files.
4. If it needs additional files, whether it's distributed as a package (apt/rpm) or chroot (container image).
Does breaking those different concepts down into a list help? You can see that trying to compare the performance of "WASM deployed as standalone binary with CGI execution model" and "native code deployed in container image" just isn't meaningful. The article is mixing up too many different ideas when trying to benchmark.