Twitter | Search | |
Ryan Toronto
I wanted a bit more insight into our FastBoot workers, so I made this UI that exposes some helpful stats for each process.
Reply Retweet Like More
Ilya Radchenko Jul 11
Replying to @ryantotweets
That's sick ๐Ÿ‘ŒIs that part of your production build or dev only?
Reply Retweet Like
Ryan Toronto Jul 11
Replying to @knownasilya
Thatโ€™s a video of our production app ๐Ÿ˜
Reply Retweet Like
Jarek Radosz Jul 11
Replying to @ryantotweets
1.5s-3s to render a page? You talked about it on the podcast, but those timesโ€ฆ man. Do you know what contributes to that? My production FastBoot response times (w/ no caching) in the last 24h were: Median 50th: 67ms Minimum 95th: 207ms Maximum 95th: 1151ms
Reply Retweet Like
Ryan Toronto Jul 11
Replying to @CvX
Few things going on that make our responses a bit slower... 1. Our webserver only does SSR from cache. If there's a cache miss we serve the client rendered app and queue up a fastboot worker to generate the response for the next request. There's some queueing overhead here.
Reply Retweet Like
Ryan Toronto Jul 11
Replying to @CvX
2. Our API servers are very slow, so I'd bet a bit of time here is spent waiting on network. I don't have hard numbers for this though.
Reply Retweet Like
Ryan Toronto Jul 11
Replying to @CvX
Btw, 50th at 67ms and 95th at 207ms is damn impressive! Even our fastest page, one that makes no network requests and only has a few components isn't faster than 500ms.
Reply Retweet Like
Ryan Toronto Jul 11
Replying to @CvX
3. Oh almost forgot this one... We inline all of our CSS, so our pages render w/o downloading any stylesheets. There's a bunch of time spent in purgecss & jsdom here.
Reply Retweet Like
Balint Erdi Jul 12
Replying to @ryantotweets
Very slick! What are the labels inside the "Request queue" table?
Reply Retweet Like
Jesper Haug Karsrud Jul 12
Replying to @ryantotweets
Nice! What are you using for tracking the processes and their timings? Seems super useful!
Reply Retweet Like
Jarek Radosz Jul 12
Replying to @ryantotweets
Hm, this one could have a big impact on processing time. Would be great to have detailed metrics. Gotta look into that! ๐Ÿ˜ƒ
Reply Retweet Like
Ryan Toronto Jul 12
Replying to @baaz
"Waiting" and "Active"
Reply Retweet Like
Ryan Toronto Jul 12
Replying to @beyondsanity
For tracking I have some wrapper code around our FastBoot visits and then an interval that reports process metrics. The data is stored and redis and then pushed out over websockets to clients.
Reply Retweet Like
Miguel Andrade Jul 12
Replying to @ryantotweets
Sick! This should be an addon. ๐Ÿ™ƒ
Reply Retweet Like
Jesper Haug Karsrud Jul 12
Replying to @ryantotweets
Makes sense to have a wrapper for it. Considering adding fastboot to our webapp as we open it up to the public, and a dashboard like this makes a lot of sense ๐Ÿ‘๐Ÿป
Reply Retweet Like
Ilya Radchenko Jul 12
I'm looking forward to a plugin system in -inspector to enable better dev addons like this.
Reply Retweet Like
Thomas Wang Jul 12
Replying to @ryantotweets @tomdale
Can the data also be logged into a file so they can be replayed?
Reply Retweet Like
Ryan Toronto Jul 12
Replying to @xinganwang @tomdale
The http request data?
Reply Retweet Like
Thomas Wang Jul 13
Replying to @ryantotweets @tomdale
And the stats for each processes. For example if I found yesterday sitespeed dropped significantly I may be able to open the log to help debug.
Reply Retweet Like