[RESOLVED] A Problem that slows down the UI (V7)

[kklosson]

Since updating to V7, my users have universally reported an issue wherein the UI becomes less and less response over a period of about 20 minutes. I have created a demonstration video that shows that the problem can be reproduced by simply refreshing a grid control about 60 times. My users sit at this application all day and I believe that refreshing the grid 60 times replicates using the system for 20 minutes in that the user is frequently refreshing this page and hence, the grid. Here is the demonstration video.

https://www.youtube.com/watch?v=JzDm9cXO6g0

Here is a link to the article that seems to be relevant to this issue:
http://scottsjewels.blogspot.com/2013/0 ... -grid.html

Note that in the article, the author refers to a "20 minute period" and the impact in single page applications, which all AwareIM applications are.

Update: I confirmed this behavior in testing (on my personal computer) where I have scant little data. Pretty much same.

[BenHayat]

I have a theory which after you do the following test, I can verify if my theory is correct.
Please do the following and do the same 60 times refresh and report back if the following action will resolve the problem.

Please go to the grids line item and REMOVE all the line items actions (you seem to have 5). Remove them, run the app and do the 60 times refresh and let me if the performance goes down or stays the same. If my theory is right, the performance should not desegregate.

[aware_support]

Thanks for this investigation. A few things:

1) Could you please test if the problem happens in version 7.1 which uses a newer version of the Kendo UI library?
If the problem doesn't happen we can probably close the case.
2) If the problem happens in 7.1 as well, could you also:
a) test Ben's suggestion above - see if this is the caused by the actions
b) test another theory - that the problem is caused by two or more pages of data, i.e. remove the data on the second page, so that there is only one page and see if the problem still happens
c) Send us a testing BSV where we can reproduce the problem. This would save us a lot of time and go a long way to fixing the problem

[kklosson]

Sure will on all. I think I can rule out 2(b) because I tested it on by dev system where there is only one page of data in that grid. I'll do these tests and let you know. Thanks Support for taking interest.

[RentProperty]

We discovered this as well while upgrading one of our systems to V7 in the last few weeks. Same code that would run perfectly in 5.9 is now getting crazy slow over the course of 15 minutes or so to a point where you have to log out and log back in again.

Then we discovered this Blog post: http://scottsjewels.blogspot.co.za/2013 ... d.html?m=1 (Same one Kingsly mentioned)
and started to play around with the auto refreshes... and we found what causes the problem is a Client side memory leak that is linked to Auto Refreshes on queries. Just refreshing normally doesn't seem to be the issue, but if you have a query (Especially one that doesn't always have focus) for instance when you have two or three tabs with queries on each, those are the ones causing the leak. So we went to all our dashboard layouts and queries that had 30 second refresh rates etc and changed them to 3600 seconds,
and also removed ALOT of unneccesary refreshes that happened when related objects where changed etc...

Now it works 100%. No slowdown anymore as far as we can tell. It is still an issue though as there are 2 or 3 of these queries that we need to refresh every 30 seconds but until Support resolves the issue we just tell clients to manually refresh.

Hope that helps.

[kklosson]

So you think it's affected by auto refresh but if you saw my video, I was manually refreshing the grid. You also said you removed other refresh actions. To me, it all points to simply refreshing the grid, however you do it. Obviously, periodic autorefresh will exacerbate the problem. So aren't you simply refreshing less often? Not to persnickety, but I want to corner the conditions that trigger this. You say it's linked to autorefresh, but I would take the "auto" out and just say it's tied to refreshes period. Do you have something definitive to say that it's autorefresh vs. just refreshing, regardless of how?

[kklosson]

Per Support's request, I ran some tests. Bottom line, there is no question that eliminating the actions in the query seems to completely eliminate the problem. In fact, I was surprised how rapidly I could press the refresh button well past 100 clicks and it just kept responding. Then after all those refreshes, the UI remained fully responsive.

I also tested my normal query with all action items intact on V7.1 beta. I was using a virtual machine with a bit of latency so I took a baseline before starting. It became clear right away that the issue still exists in V7.1. No question in my mind about that. We would like to know if RentProperty's grids also have one or more actions on a query that was being regularly refreshed. I think in my case, normal system use would have this query refreshing all the time as the user goes about his work.

If needed, I can provide my BSV and sample data to support as a reference. No question the action items are a key part of the problem. Hat tip Ben for that one.

[BenHayat]

Ok, the problem is that, the # of raising "OnClick" event handler on the client side jQuery for actions of each row. It seems like currently the OnClick event handler takes places for every row in the grid times the number of OnClick actions times refresh times. This combo uses a lot of memory in the browser and Support needs to change how the raising Onclick event handler is implemented for each row.

So, if you have 20 rows and 6 actions (5 plus a drop down), that is 120 OnClick event handlers in memory. You multiply that by 60 refresh, that becomes 7,200 OnClick event handlers that page in memory. That WILL slow it down greatly.
I think When Version introduced combining a rows action into a single drop down, this bug was introduced.

Note: If the OnClick event handler is implemented when a row is selected and not when created at server side, then it will eliminate this problem.

[aware_support]

Please retest this in build 2180 that has just been released.

We have never reproduced the slow-down, but the popup menu with actions did create a toolbar widget that was never destroyed when the query was refreshed.

[RentProperty]

Hi Kingsly, Certainly. My intention was not take away from the fact that it is or was a very urgent and important issue to be addressed (Apologies if that is how it came across). I just wanted to share a short term solution that worked for us. Didn't have time to do tons of testing since we were porting one of our flagship products and had already announced a release date before we discovered this problem. So we couldn't wait for support to first fix it and needed to find a workaround until they resolved it.

It does make sense that the operations is actually the thing causing the problem whether it is auto refreshed or manually refreshed since the main query that was auto refreshing had 6 operations and showing 30 rows, refreshing every 30 seconds. So yeah... that would be 21600 operations in one hour... I can see that that can cause huge memory leaks if not destroyed properly upon any type of refresh.

Hopefully 2080 will resolve this issue for good.

[BenHayat]

Kinsley, please test it against 2018 and hopefully the OnClick Event handler is resolved by disposing it.

[kklosson]

RentProperty: no apologies needed, I just want Support to have clear picture and what actually causes the problem.

Ben Hayat: I plan on it.

[BenHayat]

Ben Hayat: I plan on it.

Thanks! This may save many issues on the client side.

[kklosson]

Running Build 2180 on a VM, same database, I noticed a distinct difference and was unable to produce a slow-down of the UI when refreshing the browse (with actions). Probably refreshed about 200 times. No doubt this would have had a serious impact on the UI under previous builds. Seems to be a fix.

[kklosson]

Just updating that I have deployed Build 2180 to production and users universally indicate that this issue is no longer a problem. Many thanks to Support for a rapid resolution.