3 ms·

I was excited when I first heard about Server Timing, until I realised it was limited to a single duration value. Being able to model an actual timeline would m

I was excited when I first heard about Server Timing, until I realised it was limited to a single duration value. Being able to model an actual timeline would make it significantly more useful.

jzelinskie 9y ago
You should really just instrument your application with metrics for a time series database like Prometheus, Influx, or OpenTSDB. You'll find a mature set of tools and methodology. Server Timing looks very naive.
- itsderek23 9y ago
  Author here. Application instrumentation - whether via Prometheus, StatsD, Scout, New Relic - solves a very different problem than this. The server timing metrics here are actually extracted from an APM tool (Scout), so you get the best of both worlds. With those tools, you do not get immediate feedback on the timing breakdown of a web request. At worst, the metrics are heavily aggregated. At best, you'll need to wait a couple of minutes for a trace. Profiling tools that give immediate feedback on server-side production performance have their place, just like those that collect and aggregate metrics over time.
gingerlime 9y ago
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.

I was excited when I first heard about Server Timing, until I realised it was limited to a single duration value. Being able to model an actual timeline would make it significantly more useful.

jzelinskie 9y ago

You should really just instrument your application with metrics for a time series database like Prometheus, Influx, or OpenTSDB. You'll find a mature set of tools and methodology. Server Timing looks very naive.

itsderek23 9y ago
Author here. Application instrumentation - whether via Prometheus, StatsD, Scout, New Relic - solves a very different problem than this. The server timing metrics here are actually extracted from an APM tool (Scout), so you get the best of both worlds. With those tools, you do not get immediate feedback on the timing breakdown of a web request. At worst, the metrics are heavily aggregated. At best, you'll need to wait a couple of minutes for a trace. Profiling tools that give immediate feedback on server-side production performance have their place, just like those that collect and aggregate metrics over time.

gingerlime 9y ago

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.