Updated May, 10th, 2022, added a paragraph on profiling non-UI operations.
Sometimes you may wonder, what’s going on in your database? Why the dashboard is loading slow? Why it takes ages to save the record? Here is our new performance profiler to help!
To start performance profiler, open dropdown menu with your name in top bar. Here, you’ll see Profiler: Off menu item. Click it to start the profiling. The page will reload and yellow bar will indicate the profiling is on.
Now perform actions you want to profile. Switch tabs, edit records, save, whatever. When done, use either user menu or a link in a yellow bar to stop profiling and examine the results.
Let’s start with something simple. Navigate to some view, turn on the profiler and once page refreshes turn it off. You’ll see the results:
And you can save the results to share with TeamDesk support team or other admins of your database.
How to interpret this? We spent 27ms to render the page. This time is counted from first byte we got till the last byte we sent.
There are two sub-entries: Calculate New Record Menu and Render ‘List All’. We do not track every sub-operation but data access as we crunch numbers really fast, but data access is the typical bottleneck. So, from 27ms for the whole page we spend 2ms to calculating actual state of New Record menu displayed under tabs and 7ms to render List All view.
Going deeper, to render the view we needed two requests for data: one to get the records to display, that’s Get View Data and another one, to get number of records and group/grand totals and averages, if any. That’s Get View Totals/Averages. We spent 3ms on each request.
Simple enough? Let’s try preview form with details:
Here it takes two web requests to display the page. First is to render master record with one data access request. Second is to display detail view for the master record, it’s the same as displaying just the view, we discussed above.
Edit form? Easy!
Here we see we needed one data request to get the record to edit and another one to populate the dropdown.
But where profiler really shines is to track what’s happening on save and custom buttons.
As a sample database we took Copy Record with Details and Sub-Details which has fairly complex copy logic. And now you have a chance to look on how internals works.
The button executes three actions – one to copy master record, one to copy the details and one to copy sub-details. Latter two actions use RecordSet columns to get the list of records to copy and repeat the action on each source record. It is all visible in profiler. There are two detail records to copy (we expanded one to see sub-operations, another one is collapsed). And there are four sub-detail records to copy.
Triggers and associated actions, web requests made by Call URL actions will all be visible in profiler results.
For non-UI parts such as periodic and time-dependent triggers, view subscriptions, webhooks, and REST API calls we collect profiler data automatically. Link to the profiler data is added to corresponding log entries.
The profiler simply collects the performance samples from the code we execute and does not alter your data or the way we process it in any way.