Troubleshooting Slow Performance

[peteconway]

Re: Troubleshooting Slow Performance

Rich some very helpful material here - thanks - RDPGuard is a good option we has a site getting hit 50 times a second so it can be a BIG deal if you are not looking out for it. Again well done with the note. Peter

[iRadiate]

Re: Troubleshooting Slow Performance

Thanks Rich, that is a great list of suggestions! Lots of good things to think about.

Much appreciated!

[iRadiate]

Re: Troubleshooting Slow Performance

I'm starting to think that my slow performance is a consequence of trying to make my application anything more than 'basic'.

What I mean is that I re-created one of my UX components but with only the bare-bones SQL based List control.
The SQL query returns 100 rows of paginated data from a data set of ~11,000 records as follows:

SQL Server Management Studio 2016 < 1 second
Bare bones UX List Component ~2 seconds
Fully styled and coded UX component ~8 seconds

https://www.screencast.com/t/Zm5lvSY2rPuX

Clearly, the SQL query on 11,000 records is definitely not the problem. The performance hit from having Alpha return the query versus SSMS alone is minimal.

This is very discouraging but I'm trying to build the component up from scratch and taking note of when things start to really slow down, is it adding the search components, is it conditional styling, is it a combination of everything other than the basic unstyled List.

[Jonathan Freestone]

Re: Troubleshooting Slow Performance

with lists we have had reasonable success swapping paginated data for list virtualization .

in paginated lists the Alpha server runs two queries, one to get the total row count, then another to get rows X to Y
in List virtualization the Alpha server runs one query to get all the rows, but the client side does not inject into the DOM (html) so it renders qucker.

Virtualization only works if you know the number of records in your list isn't going to grow massively over time e.g. we use it quite successfully in our web shop where we know the list of available stock is unlikely to ever go over 8,000 lines.

virtualization also works best with client side filtering, as searching can appear near instant.

But yes our web portal takes ~8 seconds to load in, but once you are in the only database calls are to save changes, everything else happens client side and is super fast. Also allows the web portal to work offline.

[iRadiate]

Re: Troubleshooting Slow Performance

Thanks Jonathon, that's interesting. I will have to investigate list virtualization further ... but my records will grow over time, it is a list of service repairs.
I recall having tried virtualization before but experiencing the same slow load time ... I don't think I paid attention to the search response times.

I am convinced that the more styling, conditional code, etc that is added to the list component, the slower it becomes at rendering. And I believe this is the crux of my problem, the components are too complex to be efficient.
I've already proved this out by making the list bare bones. This takes a load time of ~8 seconds down to ~2 seconds (only slightly slower than the native SQL query using SSMS).

[CharlesParker]

Re: Troubleshooting Slow Performance

The single most important thing I did was to break down my large components into smaller ones set within separate panel-cards, then set to delay render. Consider what needs to be accomplished in each panel-card, if its read only then render it without a detail view, you can always embed a list with a detail view that can be called when needed.
Breaking things down also makes application management a bit easier to update and make changes without breaking the whole thing when something goes awry so there are definitely benefits to compartmentalizing besides speed but it will most likely yield the best results in terms of load times.