Comment by ashishb
3 months ago
How is Rust + Web Assembly + Cloudflare workers in pricing and performance compared to say deploying Rust-based Docker images on Google Cloud Run or AWS Fargate?
3 months ago
How is Rust + Web Assembly + Cloudflare workers in pricing and performance compared to say deploying Rust-based Docker images on Google Cloud Run or AWS Fargate?
Rust on CF Workers is horrible. >10x performance hit (compared to JS) for a non-trivial web app, and it's not only a 10x performance hit but 10x the cost since they charge for CPU time, and that's where the extra time is going.
Realistically for a low traffic app it's fine, but it really makes you question how badly you want to be writing Rust.
As far as I can tell, the problem stems from the fact that CF Workers is still V8 - it's just a web browser as a server. A Rust app in this environment has to compile the whole stdlib and include it in the payload, whereas a JS app is just the JS you wrote (and the libs you pulled in). Then the JS gets to use V8's data structures and JSON parsing which is faster than the wasm-compiled Rust equivalents.
At least this is what I ran into when I tried a serious project on CF Workers with Rust. I tried going full Cloudflare but eventually migrated to AWS Lambda where the Rust code boots fast and runs natively.
I thought WASM was no_std since there's no built in allocator?
Regardless, not sure why a Rust engineer would choose this path. The whole point to writing a service in Rust is that you would trade 10x time build complexity and developer ovearhead for getting a service that can run in a low memory, low CPU VM. Seems like the wrong tools for the job.
> Seems like the wrong tools for the job.
Thanks for the confirmation. I was confused as well. I always thought that the real use of WASM is to run exotic native binaries in a browser, for example, running Tesseract (for OCR) in the browser.
I think performance takes a hit due to WASM, and I imagine pricing is worse at big qps numbers (where you can saturate instances), but I've found that deploying on CF workers is great for little-to-no devops burden. Scales up/down arbitrarily, pretty reasonable set of managed services, no cold start times to deal with, etc.
Only issue is that some of the managed services are still pretty half-baked, and introduce insane latency into things that should not be slow. KV checks/DB queries through their services can be double-to-triple digit ms latencies depending on configs.
The performance hit is less because of WASM but because the Workers platform is fundamentally defined in terms of Javascript and WASM is just a thing the JS engine has as a feature, so everything has to be proxied through JS objects and code, serialized into byte arrays, handed to the WASM, and same story in reverse.
We need WASM-native interfaces to get common to get rid of JS.
I ended up using container service on azure for a small rust project that I built in a docker container and published to GitHub. GitHub actions publishes to the azure service and in the 3 years I have been running it, it's basically been almost entirely free.
I have a similar experience except I use Go+GitHub Actions+Google Cloud Run.