Shift notification table speed changes ¶
Issue(s) ¶
As of early 2020, the vue-bootstrap toolkit is used as the basis for most of the IV UI work. However, the b-table component is moderately slow, and relatively naive out of the box.
The other aspect of the slowness is the data retrieval from the server.
Some indexes help speed up some of the SQL, but the ‘conversion to JSON’
process (using the base Laravel ‘resources’ pattern) - is slow.
Part of the reason for its slowness is that the current process will
do a lot of lazy loading on the shifts (for site/location/employee/etc).
Modifying this to a more eager-loading approach (and ensuring some indexes in place)
cut data generation time by around 40%.
Most recently noted in Trello ticket 392 https://trello.com/c/hjCURQIx/392-slow-loading-production-pages-notified-and-open-pages
They’re saying 20+ seconds. A reduction of 50% may still only get them to 10 seconds.
Initial fixes ¶
- Add more indexes to shift
- Eager loading
- Explicit filter function
- Reduce data created/sent in resource payload
- Modify tables to use the reduced payload data
Future ¶
These changes will definitely buy some time - some UI changes to open new tabs by default would also allow for the main tables to remain on screen without needs for reloading/refreshing as often as may be being done now.
Longer term, swapping to a more robust datagrid may buy some additional features which will be helpful to the client-side filtering which the current datagrid doesn’t offer (date range filtering, direct data export, column based searching, etc).
Loading data via api calls, while displaying a loading/progress indicator, would provide a friendlier experience, even if the data still takes longer than they’d like.