containerd-shim-spin icon indicating copy to clipboard operation
containerd-shim-spin copied to clipboard

Redundant file copies for every pod start

Open radu-matei opened this issue 1 year ago • 3 comments

The startup time for a Spin application distributed as an OCI artifact is affected by several copies of the Wasm components and static assets on disk.

  • first, we write the OCI layers returned by runwasi on disk, in a directory structure that follows Spin's OCI loader: https://github.com/spinkube/containerd-shim-spin/blob/a42715e542a167d7b02a6725cf6d6d0fa96c1912/containerd-shim-spin/src/engine.rs#L104-L141
  • we then call load_from_cache (https://github.com/spinkube/containerd-shim-spin/blob/a42715e542a167d7b02a6725cf6d6d0fa96c1912/containerd-shim-spin/src/engine.rs#L165), which in turn calls Spin's loader, which copies the files into a temporary directory: https://github.com/fermyon/spin/blob/7f55409a7b75c8dc52bc77fdaa5ba1e71a524b8d/crates/oci/src/loader.rs#L103

Since this time is spent on every pod start, my assumption is that it affects performance, in particular for applications with a higher number of components and assets.

I'd like to see if we can improve this, potentially by implementing a Spin application loader that directly uses the runwasi list of WasmLayers and skips all the copies.

radu-matei avatar Mar 13 '24 11:03 radu-matei

Another idea along these lines that I had would be to implement an In-memory cache provider that would skip the write to disk as well.

jsturtevant avatar Mar 13 '24 17:03 jsturtevant

Hi @jsturtevant, just trying to understand your suggestion here. are you saying to have these static assets loaded in memory and serve from there?

rajatjindal avatar May 23 '24 06:05 rajatjindal

Yes, they are already in memory via the WasmLayers struct. There is a concept of a Cache in Spin which currently reads from a specific folder, which is why we write the files to disk. I thought we might be able to create a new implementation of the cache that reads from the pre-loaded memory instead of writing to disk then reading it again. This would speed things up a bit by avoiding the IO but may not be ideal in all cases when the there are lots of files.

jsturtevant avatar May 23 '24 20:05 jsturtevant