3 ms·

The screenshot shows a breakdown of timing by component (Middleware, router, view, etc). Or perhaps I don't quite understand what you mean by "model an actual t

The screenshot shows a breakdown of timing by component (Middleware, router, view, etc). Or perhaps I don't quite understand what you mean by "model an actual timeline"? As a side note, we've been using miniprofiler[0] for a long while now, and it has some limitations, but can be very useful some times. [0] https://github.com/MiniProfiler/rack-mini-profiler https://github.com/MiniProfiler/rack-mini-profiler

kaycebasques 9y ago
I think I get what OP is saying. The screenshot [1] shows you the aggregate time of each arbitrary component, but it's not mapped out along a time series, like you see in the Network panel's Waterfall or in a Performance recording. I'll see if there's anything we can do on our side (I'm the DevTools tech writer), but I think it's an API limitation. We might be able to use some arbitrary convention in the timing values that let's us plot along a time series... [1] https://camo.githubusercontent.com/bc62621acd195d11d0247c0cc8087f48604ba064/68747470733a2f2f73332d75732d776573742d312e616d617a6f6e6177732e636f6d2f73636f75742d626c6f672f727562795f7365727665725f74696d696e672e706e673f78 https://camo.githubusercontent.com/bc62621acd195d11d0247c0cc...
- itsderek23 9y ago
  > but I think it's an API limitation Author here - I believe that's the case. There isn't a way to specific start & end time: https://w3c.github.io/server-timing/#dom-performanceservertiming https://w3c.github.io/server-timing/#dom-performanceserverti... That said, the spec also mentions: > To minimize the HTTP overhead the provided names and descriptions should be kept as short as possible - e.g. use abbreviations and omit optional values where possible. I could see significant issues if we tried to send data in timeline fashion (such as creating a metric for each database record call in an N+1 scenario). One idea: pass down an URI (ie - https://scoutapp.com/r/ID https://scoutapp.com/r/ID) that when clicked, provides full trace information.

kaycebasques 9y ago

I think I get what OP is saying. The screenshot [1] shows you the aggregate time of each arbitrary component, but it's not mapped out along a time series, like you see in the Network panel's Waterfall or in a Performance recording. I'll see if there's anything we can do on our side (I'm the DevTools tech writer), but I think it's an API limitation. We might be able to use some arbitrary convention in the timing values that let's us plot along a time series... [1] https://camo.githubusercontent.com/bc62621acd195d11d0247c0cc8087f48604ba064/68747470733a2f2f73332d75732d776573742d312e616d617a6f6e6177732e636f6d2f73636f75742d626c6f672f727562795f7365727665725f74696d696e672e706e673f78 https://camo.githubusercontent.com/bc62621acd195d11d0247c0cc...

itsderek23 9y ago
> but I think it's an API limitation Author here - I believe that's the case. There isn't a way to specific start & end time: https://w3c.github.io/server-timing/#dom-performanceservertiming https://w3c.github.io/server-timing/#dom-performanceserverti... That said, the spec also mentions: > To minimize the HTTP overhead the provided names and descriptions should be kept as short as possible - e.g. use abbreviations and omit optional values where possible. I could see significant issues if we tried to send data in timeline fashion (such as creating a metric for each database record call in an N+1 scenario). One idea: pass down an URI (ie - https://scoutapp.com/r/ID https://scoutapp.com/r/ID) that when clicked, provides full trace information.