Status-react: [Perf] Test hypothesis 6: re-frame queue throughput causes bad app responsiveness

[mandrigin]

Identified Behavior

Not well defined in a specific user story yet, but generally: app responsiveness is bad.

• [ ] User story part of MVP scope
• [ ] Identified end user behavior

Hypothesis

There exists UI events which aren't processed in <= 0.3 seconds, from the time of queueing it to the time of execution. This delay causes the user to feel the app isn't generally responsive.

Assumptions

• The app responsiveness depends on the re-frame queue throughput
• App responsiveness is generally bad for MVP user flows

Experiment

The app responsiveness depends on the re-frame queue throughput. We need all the UI events to be processed (from the time of queueing it to the time of execution) in <= 0.3 seconds.

We should add some responsiveness metrics and print out a warning if the budget is exceeded.
(We can also print out the queue state or the queue element that takes too much time).

Responsiveness metrics and threshold values

1. Queue throughput (<0.3 sec)
2. Queue size (<10 items)
3. Event processing time (<0.2 sec)

Acceptance criteria

• [x] Measure queue throughput
• [x] Measure queue size
• [x] Measure event processing time
• [x] Print warning (incl in release builds) if limits are exceeded
• [ ] Issue created for the biggest offenders, if they exist

[dmitryn]

https://github.com/Day8/re-frame/blob/master/src/re_frame/router.cljc#L8

[mandrigin]

@dmitryn thanks! I'll try forking it and take a look if I can add simple log messages to it, to begin with.

[oskarth]

This user story seems like a good candidate to test for these things. https://github.com/status-im/status-react/issues/3095, FYI @mandrigin

[mandrigin]

The patched version of re-frame (WIP): https://github.com/mandrigin/re-frame/tree/igorm/re-frame-perf-metrics

It is possible to set it up to your local Maven repo with lein install.
Then tweak the dependency in project.clj -> [re-frame "0.10.2-igorm"].

The values are hard-coded there: 300ms for throughput, 100ms for an item, 100 items in the queue.
I'll continue working to both tweak the values and add more debugging info (like current event, or something).

GitHub

mandrigin/re-frame

re-frame - A Reagent Framework For Writing SPAs, in Clojurescript.

[oskarth]

@mandrigin @dmitryn What's the state of this experiment?

[dmitryn]

What's the state of this experiment?

@oskarth We now have Status fork of re-frame https://github.com/status-im/re-frame/tree/0.10.2

@mandrigin could you please put changes from your fork to the Status one? (please make sure you create your branch on top of 0.10.2)
So we could use queue timings logging in case we need to debug slow parts of the app. By default, debug logging is off.

GitHub

status-im/re-frame

re-frame - A Reagent Framework For Writing SPAs, in Clojurescript.

[mandrigin]

@dmitryn sure! I'll start doing that today then.

[oskarth]

@dmitryn @mandrigin Thanks!

To clarify, what does this fork and work around it imply for the following? Are the first 4 done? Are there any issues for number 5?

Acceptance criteria

• [ ] Measure queue throughput

• [ ] Measure queue size

• [ ] Measure event processing time

• [ ] Print warning (incl in release builds) if limits are exceeded

• [ ] Issue created for the biggest offenders, if they exist

[mandrigin]

@oskarth in my fork the first 4 are done. @dmitryn you told me you used my fork to profile something, were there any actual issues uncovered?

[dmitryn]

@mandrigin i was using it to profile account creation workflow which is known to be slow https://github.com/status-im/status-react/issues/3111

I'm going to enable queue logging while will be testing https://github.com/status-im/status-react/pull/3332 to understand where we still have blockers and long-running tasks.

[oskarth]

Thanks @mandrigin and @dmitryn!

[mandrigin]

outdated, closing