[garganzol]

I took a quick look at the examples that come with mod_wasm module: from what I could see, the HTTP/WASM interface is based on CGI.

I kind of like it because CGI is architecturally elegant, but what about performance implications? By default, the CGI is not the fastest thing on Earth. Every time a HTTP request arrives, a CGI process should be initialized over and over again wasting CPU time on BSS section / runtime library initialization. Does it work any differently when it comes to WASM?

[ereslibre]

> I kind of like it because CGI is architecturally elegant, but what about performance implications? By default, the CGI is not the fastest thing on Earth.

(Wasm Labs dev here) We haven't yet measured performance in a meaningful way that we can use to compare, mainly because our PHP builds also have certain limitations mentioned in the article, such as not having OPcache available at PHP. It is however an iterative process, and we are interested in this, as well as we understand that it's interesting for the community.

> Every time a HTTP request arrives, a CGI process should be initialized over and over again wasting CPU time on BSS section / runtime library initialization. Does it work any differently when it comes to WASM?

It's a little different in Wasm, in the sense that there is no need to fork/exec (if talking about bare CGI). The PHP executable gets loaded into the runtime once (what will compile it from Wasm -> native ISA), and then for every request we create a Wasm execution context, and run the PHP Wasm module that interprets the PHP script.

Creating a Wasm execution context is certainly much lighter than a fully fledged fork/exec.

[angelmm]

Wasm Labs dev here :)

In mod_wasm, there are some differences with a pure CGI implementation. When Apache boots, it loads the configuration and initializes the WasmVM. When a new HTTP request arrives, the VM is ready so you don't need to initialize a different process to manage it.

You still need to process the request and pass the data to the Wasm module. This step is done via STDIN through the WebAssembly System Interface (WASI) implementation [0]. The same happens in the opposite direction, as the module returns the data via STDOUT.

So, the CGI pattern is still there, but it doesn't require new processes and all the code runs in a sandbox.

However this is not the only way you can run a Wasm module. In this specific case, we use CGI via WASI. In other cases, you may compile a module to fulfill a specific API, like ProxyWasm [1] to create HTTP filters for proxies like Envoy.

- [0] https://wasi.dev/

- [1] https://github.com/proxy-wasm/spec

[garganzol]

> when a new HTTP request arrives, the VM is ready so you don't need to initialize a different process to manage it.

I suspected that, pretty smart. I presume that a WASM module state can be cached in a similar way, essentially imitating a "fork" syscall semantics while keeping the pool of request handlers in a always-ready hot state.

[mobilio]

Or better PHP-FPM?

[ridruejo]

Kind of what you want, with wasmEdge and FastCGI https://wasmlabs.dev/articles/wordpress-nginx-fcgi-mysql/