RichContentEnabled

How to debug performance issues

Many of the performance issues we encounter in our apps are caused by long-running JS code that blocks the JS thread, causing bottlenecks and prevents other code from running; for example, if the JS thread is busy it can't receive events from the native side, even though the native views can still be interacted with (for example: button press callbacks, scroll events, etc.), causing lags and ultimately result in an unresponsive app and a not so great experience for our end users. 

In this guide, we will go over all the tools we currently have to diagnose and analyze which components/modules have performance issues.

Performance BI events

Most of our current tools and monitoring capabilities are based on BI event 1332 which is sent automatically for all the registered screens in our apps. This is helpful both for monitoring in production, but also for debugging locally. All performance related measurements are sent via this event.

Available events

• ComponentLoad: measures the complete time it took for a component to show. It's the sum of the time it took for the constructor, the componentDidMount, and the first render to run, including re-renders.
• RNN.ComponentDidAppear: measures how long react-native-navigation component appear event took to run. In case you're performing some long-running operation there it won't delay showing the screen, but since it happens almost immediately after the component is loaded it delays the time that the user can interact with the screen, leading to poor experience.
• RNN.ComponentDidDisappear: in a similar manner to the previous event, this measures RNN's component disappear time. This also affects the time for interaction but for the screens that comes next (when you push a new screen), or the previous screen (when you pop);
• woa-engine.invoke: measures how long it took to execute an invoked method. The time includes async operations like network calls, so it reflects the actual impact during this time the user is probably waiting for something to happen.
• woa-engine.component: measures the mount time of a component when the withPerformanceBI API is used (note: this is not exactly like the ComponentLoad event, it only measures the time from constructor to componentDidMount).

Find out which screens perform poorly

Tableau dashboards

We currently have 2 kinds tableau reports:

• Ranking modules performance: this includes reports about the overall module rank based of the best/worsts performing screens. The most useful dashboard here is probably the Investigate Modules table where you can select your own module and see the list of screens and how well they perform, as well as the number of users who experienced it which is also important for setting priorities for what should be addressed first.
• Daily Performance Report: reports with graphs that are sent daily for the overall time and important screens. A really nice tool here is the Investigate by Screen Name and Module report which can provide great insights about screen performance trends for individual screens, helping with identifying when performance degradations occured.
• Apdex Dashboards: the Application Performance Index, also known as Apdex provides a numeric score for the good/bad sessions' ratio. Every session under 300ms count as good session. Our goal is to reach 95% of good sessions.

column1	column2	column3	column4	column5	column6	column7	column8	column9
row1	11	12	13	14	15	16	17	18
row2	21	22	23	24	25	26	27	28
row3	31	32	33	34	35	36	37	38
row4	41	42	43	44	45	46	47	48
row5	51	52	53	54	55	56	57	58
row6	61	62	63	64	65	66	67	68
row7	71	72	73	74	75	76	77	78
row8	81	82	83	84	85	86	87	88