4 ms·
(one of the authors of Spin here.) WIth the disclaimer that this is really early, and we don't have extensive benchmarks yet, there are a few things we are tra
by matei_radu 5y ago
(one of the authors of Spin here.)
WIth the disclaimer that this is really early, and we don't have extensive benchmarks yet, there are a few things we are tracking for HTTP workloads (you can see the actual benchmark apps here — https://github.com/fermyon/spin/tree/main/crates/http/benches https://github.com/fermyon/spin/tree/main/crates/http/benche..., and the rendered results here — https://fermyon.github.io/spin-benchmarks/criterion/reports/ https://fermyon.github.io/spin-benchmarks/criterion/reports/):
- the response times — here are some benchmarks for requests that simulate 1 ms of work — https://fermyon.github.io/spin-benchmarks/criterion/reports/spin-executor_sleep-1ms/index.html https://fermyon.github.io/spin-benchmarks/criterion/reports/...
- the "cold" startup time — https://fermyon.github.io/spin-benchmarks/criterion/reports/startup/spin-executor/index.html https://fermyon.github.io/spin-benchmarks/criterion/reports/...
Another disclaimer is that we have not focused on optimization work at all, so we expect to make significant improvements over the next few months.
- technosophos 5y ago(Another Fermyon person here) On a lighthearted unscientific note: After getting absolutely bombarded with traffic today (5-10x normal, YAY!), we noticed: - No increased latency in responding to requests - Flat memory usage at 130MB per worker (we run Nomad) - Spiky CPU traffic (which is expected when starting and stopping Wasm modules hundreds of times a second), but never really over about 60% of the CPU on a small VM size on AWS - No Wasm downtime (though we did have a non-Wasm load balancer hiccup at about peak load, cause unknown)