Add db_runtime and view_runtime to middleware

[Manfred]

• As a developer I want to see db (and view) runtime for my benchmark requests so I can figure out where the application can be improved.

In Rails 5 we can get db_runtime and view_runtime for a controller action through Active Support notifications. It might be interesting to add these to the response headers.

At which point does it make sense to encode multiple values in one header? For example:

X-PerfCheck: db_runtime=0.23,view_runtime=0.54,query_count=3

[sudara]

+1 for db_runtime, nice idea.

I always forget if rails' concept of that includes AR object instantiation or not. I've looked that up like 10 times over the years. If not, we should provide guidance that the db impact looks (in some cases much) smaller than the reality is.

I guess we should also include some default absolute and relative thresholds in these cases.

I'm not a huge fan of view_runtime in rails... it's somewhat of an unhelpfully named bucket that ends up collecting most of the non-explicitly collected db time one way or another. I've found it rarely adds useful signal to for people when troubleshooting. I'm happy collecting it but leaving it out of presentation/calculation for now unless you feel strongly that it's a valuable signal.

Up to you if you want to encode them all in a header. Not against it.

[Manfred]

I'm pretty sure it's just time spend executing in the database driver (so it includes the roundtrip to the server). I'm not sure where and if we need to add this information and how we should process it. I wanted to start by exposing it and probably gathering it.

[sudara]

Sounds right to me. I prob have a rails project somewhere that confirms that instantiation is excluded.

Instantiation of large numbers of records is a regular confusion for people that sometimes leads them to dismiss db as the root cause: "My query executed in 'only' 30 seconds, where is this other 2 minutes of time coming from?"