Recently I learned about the recent effort of the w3c to standardize the Server-Timing API. The goal of this API is to standardize a way to exchange information between the server and the browser about performance metrics on the server side within that exact request.
In the most recent Chrome Canary builds (Version 66) the developer tools already read and display the data nicely.
– Image credits Thomas Steiner
I wanted to inspect how easy it would be to use this in my most favorite web framework: Phoenix.
We need a point to hook into the request/response cycle, writing a custom Plug would be perfect for this. So created a new Phoenix app to test this and wrote this little custom Plug.
A quick note on the weird caseing of the headers: Regarding HTTP RFC 7230 a sender MUST NOT generate multiple header fields with the same name*. That is why Plug does not support setting the same header twice, but rather updates it. This is a way to work around the Limitation.
You can read more over here: https://github.com/elixir-plug/plug/issues/660
And hooked the plug into the default browser stack of Plugs.
With this little setup I was able to see my phoenix app timing within the chrome developer tools.
This is a proof of concept. The app is blazing fast because it is empty (and it is Elixir). A real app could emit way more interesting metrics and with just a little bit more effort you could extract the real DB numbers from Ecto and use them within that plug. You could extract the numbers from Ecto using the
While looking at the results I noticed even being that early in the process there is still 450 ms to the first byte TTFB. So in order to get deeper insight on where the time on the server is spend we would need to move this code closer to the actual web server. In the example of phoenix it would be the cowboy web server. If cowboy would support this we could get some more interesting numbers.
In his closing keynote at Elixir Conf EU 2017 in Barcelona Chris McCord talked about how Phoenix wants to standardize metrics within Phoenix. I think this would be a great way to report the collected metrics to the browser and thus expose them to the developers and help everyone to build even fast phoenix applications.
Conference junkie, user groupie and boardgame geek also knows how to juggle. Oh, and software.
Configure DNSimple as your secondary DNS provider to improve your domain's availability and redundancy with AXFR zone transfers.
Get a free limited-edition t-shirt featuring the characters of howdns.works and howhttps.works with any new yearly subscription to DNSimple.