| Is it possible you don't have direct experience with CGI? 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. |
I think what the article is implicitly doing is comparing WASM bytecode running under a container runtime that executes it directly (e.g., without a full chroot). Your point, iiuc, is that there are many variables here, of which x86 vs WASM is only one, and that the benefits here might not be due so much to WASM so much as they are due to the other factors.
I didn't understand where CGI-ness comes into it though, as I don't think there's any difference between this kind of container and any other in terms of the duration or when it's starter up, but perhaps your point is that it's lacking some "full" environment, which makes is akin to CGI? I guess a more accurate comparison would be against an x86 binary being executed with some kind of minimal docker runtime, then? I guess the article could be interpreted generously then as a comparison between a thin docker runtime and a thick docker runtime.