Clojurians Log v2

I've been working on a doc at work re: our strategy for tracking performance of our reagent/react SPA. here's the basic rundown so far: * we will need to manually instrument our code with events that record the current time and store them. currently looking at using the browser's User Timing API for this * we'll have to manually relate these events later into spans and measure the duration between events (again using User Timing API), then send these measurements to some backend - currently looking at google analytics User Timings, and/or sending them to our backend metrics recorder so they show up in grafana we're also interested in tying this in with our backend observability tooling by sending these events to honeycomb so that we can see spans from client -> api -> service -> db -> service -> api -> client

@roman01la @martinklepsch

so far my research has shown that this is sort of the lowest common denominator for using all the APM services out there.

We are instrumenting our code with user timings API as well, works good and wasn't hard to do

In fact we are using performance mark/measure, so that those spans are also visible during debugging in chrome's devtools

nice, glad to hear that's working well - that's what I'm assuming we would use now but wasn't sure how well it worked in practice

how do you know when to call performance.measure() ? do you relate the marks together in code somehow?

We have multiple kinds of measures 1. Navigation: time from user interaction that triggers navigation to when Reagent flushed a specific component into the DOM 2. Text editing: average time per editing session where we measure time from keydown event to when text rendered on a screen 3. Dragging FPS: amount of frames recorded via raf / time user spent dragging something on a screen

And also initial loading time, that just uses a value from user timings object populated by a browser

I don't know what Grafana offers, but we are currently using datadog for perf metrics and it works well so far. The tool provides interesting capabilities such as anomaly detection and alerting

nice

after you've marked and measured using the user timing api, do you send those directly to data dog immediately?

Sending is throttled, meaning events are sent in batches

Not sure if this could be useful for you, but it's interesting to look at metrics graphs having info about user downlink speed, there's browser API for that

That helps to distinguish loading times on fast and slow connections

Also depending on the type of product it could be useful to put users in diff buckets based on amount of data that directly impacts performance

For example in our case one of the metrics puts users in diff buckets depending on the size of a presentation they are opening

I guess there's little info about perf metrics for rich web apps because they are diff for every product, unlike websites like medium or online shops where everything boils down to optimizing for loading times

right

so it sounds like you've hooked into the reagent lifecycle? or into react's lifecycle?

I found this resource to be very useful https://calendar.perfplanet.com/2020/ from there you can find interesting people in web perf world and follow their work

> so it sounds like you've hooked into the reagent lifecycle? or into react's lifecycle? Regent lifecycle, yes

Are you doing any perf testing on CI?

we are currently doing no perf testing or measuring 🤪

other than one or two ad hoc things

I'm guessing that pitch is far more of a perf sensitive app than ours so I'm happy to learn what you're doing

I see, we are about to work on testing and there's also nothing on that topic, hehe

one of the complications I foresee when I was thinking through perf testing is that I want to replicate the type of conditions that a user would actually be interacting with our app

so outside of simple benchmarking, I don't really know how useful it would be to measure some over-crowded CI server navigating our app through headless chrome

my view atm is that it could be useful and most importantly reliable for testing UI interactions that purely depend on computations happening on client side, avoiding network basically

dragging stuff around, typing into input fields etc

I'm basing this on my experience w/ using cypress in CI, which is that weird things happen when you put tests like that on a box running linux and headless chrome with a bunch of other processes running on it

e.g. some parts of our app were written using re-frame subs controlling text inputs, which meant a bit of lag on most clients but would occasionally flake out and drop key presses when cypress tests ran in CI

That's my worry as well, btw Cypress doesn't recommend to use it for perf testing since they are intercepting and controlling timer APIs and a bunch of other things I believe

right - we use cypress for E2E and integration testing. was using it as the source of my fear re: how apps perform in CI

cypress and I are on bad terms rn 😛

I wonder on which UI platforms it's more common to run perf tests? Mobile maybe?

that's a good question. you would think this would be solved