Provide resource usage as part of `spin up`

[mikkelhegn]

Somewhat tangential to #2933.

It would be great to have a flag (or potentially a plugin) to Spin, which will output three metrics from running a Spin app locally:

1. CPU Times spent (min/avg/max)
2. Execution time (min/avg/max)
3. Memory usage (min/avg/max)

With min/avg/max being across the requests handled while Spin was running a given application.

Further improvement being splitting by component, while maintaining total.

I'm imagining something like:

> spin up --enable-spinfo
Logging component stdio to ".spin/logs/"

Serving http://127.0.0.1:3000
Available Routes:
  demo-ts: http://127.0.0.1:3000 (wildcard)
^C⏎

-- SpInfo
Total:
# of invocations:                             200
CPU Times spent (min/avg/max)   1ms/2ms/5ms
Execution time (min/avg/max)       10ms/20ms/30ms
Memory usage (min/avg/max)       5MB/10MB/10MB

Component 1:
# of invocations:                             200
CPU Times spent (min/avg/max)   1ms/2ms/5ms
Execution time (min/avg/max)       10ms/20ms/30ms
Memory usage (min/avg/max)       5MB/5MB/5MB

Component 2:
# of invocations:                             100
CPU Times spent (min/avg/max)   0ms/1ms/2ms
Execution time (min/avg/max)       5ms/10ms/20ms
Memory usage (min/avg/max)       5MB/5MB/5MB
>

[mikkelhegn]

The motivation for this, as a separate idea to #2933 is to make it an easy developer experience to benchmark / get information about the components resource consumption, without the need for an OTEL stack and the ability to write queries to get those metrics.

[vbmade2000]

@mikkelhegn I want to try this to start with contribution to this project.

[tschneidereit]

@vbmade2000 that'd be fantastic! <3

I have a work-in-progress patch for this over here. It doesn't provide the same interface as what Mikkel is describing, and is decidedly not complete, but it might give you a starting point for the implementation. Though note that I'm not even claiming that the approach I took there is the best one, so take this as inspiration if you want :) In any case, please feel free to take however much or little of that change as you'd like, in whichever way you'd like.

To see it working, so you can see what's there right now, you can run the following after applying the patch:

RUST_LOG=info cargo run -- watch -f examples/http-rust

And then visit the hello route once it's up.

[vbmade2000]

@vbmade2000 that'd be fantastic! <3

I have a work-in-progress patch for this over here. It doesn't provide the same interface as what Mikkel is describing, and is decidedly not complete, but it might give you a starting point for the implementation. Though note that I'm not even claiming that the approach I took there is the best one, so take this as inspiration if you want :) In any case, please feel free to take however much or little of that change as you'd like, in whichever way you'd like.

To see it working, so you can see what's there right now, you can run the following after applying the patch:

RUST_LOG=info cargo run -- watch -f examples/http-rust

And then visit the hello route once it's up.

That would be a good start. I'll take a look. Thanks @tschneidereit :)

[vbmade2000]

@mikkelhegn @tschneidereit # of invocations is number of instances created for each component, correct?

[tschneidereit]

@vbmade2000 not quite, though correct in most cases. Number of invocations is the number of incoming http requests. We might instantiate multiple components to serve a request, though for now that's the less likely case.

I think that nevertheless it'd be good to use trigger invocations for this, not instantiations.