Multithreading is the concurrent execution of multiple threads within one process or application. For server workloads, it matters because concurrent requests can use more than one CPU core instead of forcing all work through a single execution path. Current Wasm support is a practical constraint: Wasm is described as single-threaded, while its threading proposal remains in progress. section 1.2.2 section 1.5
This limitation is most visible under load. In one evaluated SQL-backed request service with 50 concurrent clients, the Wasm application reached roughly 15.2 seconds worst-case latency, compared with 0.881 seconds for a Docker container. Removing containerization did not eliminate the gap: the Docker setup was still nearly 13 times faster. The cited explanation is CPU use: Docker increased utilization to 11 cores, whereas Wasm used one. section 1.2.2
Treat the constraint as an architecture decision rather than a reason to discard Wasm outright:
- Expect traditional PaaS-style applications to struggle when high concurrent throughput depends on multithreaded execution. section 1.3
- Use a runtime setup that starts a separate Wasm instance for each request when that operating model fits the service. section 1.2.2
- Reduce the effect through horizontal scaling: run containerized application replicas under Kubernetes rather than relying on one instance to occupy many cores. section 1.3
- Balance throughput needs against cold-start and artifact-size advantages. The evaluated Wasm container had about 160% faster cold starts and can avoid packaging an operating system. section 1.2.2
Reading a load-test result
A slow Wasm result under concurrent load is not, by itself, evidence that containerization is the cause. Compare the same workload outside the container, inspect how many CPU cores the runtime can use, and then decide whether request-per-instance execution or horizontally scaled replicas match the workload. This separates a threading limitation from container overhead. section 1.2.2 section 1.3
Table 1.1 Comparing Wasm to traditional technologies across key dimensions
| Capability |
Wasm |
Traditional technologies |
|---|---|---|
| Sandboxed execution |
Built-in, lightweight isolation |
Containers (not as secure), VMs (heavy/slow), or language-specific (Java, .NET) |
| Cold start |
Microseconds |
Containers: seconds; VMs: minutes |
| Artifact size |
KBs to low MBs |
Containers: 100s of MBs; traditional: varies widely |
| Portability |
Compile once, run anywhere |
Docker (platform-specific builds); interpreted languages (performance penalty) |
| Memory footprint |
Minimal overhead |
Containers/VMs: significant overhead |
| Multithreading |
Limited (proposals in progress) |
Well supported |
| Ecosystem maturity |
Growing (many packages incompatible) |
Mature |
| Debugging tools |
Improving but limited |
Well established |
| Runtime performance |
Near-native |
Varies (native to interpreted) |
Use the comparison table to weigh limited Wasm multithreading against its sandboxing, cold-start, artifact-size, portability, and runtime-performance characteristics. section 1.3
