Chrome issue (Web version)

[marminatix]

Hi. I'm testing an application handling some simple data transfer with a "push" data acquisition and a maximum of 1 per second refresh rate. On the Android interface it seems all right and correctly updating numbers and graphs. On the web side (chrome browser) the flow, on superchart "latest" refresh rate, seems to periodically freeze, the browser begins to use a lot of CPU and the fan starts running. Refreshing the webpage doesn't work properly (the browser tries to update but without success) and doesn't solve the problem. Solving means to close the webpage (not the browser) and open again. I'm sure that the issue comes from the Blynk page and only when the device is "visible" like in the screenshot below. In the second screenshot you can see an example of chrome CPU utilization (intel i7). It usually varies between 70% and 90%... Thanks M

[doom369]

@marminatix I suppose you're using "Raw" source for the Graph. Right?

[marminatix]

Sorry. I've seen such an option of "raw" data but don't rememeber "where". Could you kindly say me where to look for? Thanks. M

[doom369]

@marminatix it's in the chart settings:

[marminatix]

All options are on "AVG of"

[doom369]

Ok. Thanks. Definitely, graph render performance issue than.

[doom369]

@marminatix fix deployed. Please let us know if bug is still there.

[marminatix]

At a first glance it seems working properly but probably it'll take some time to be sure. In the meanwhile, I close the issue. If I'll see the issue again I will reopen. M

[marminatix]

I'm sorry. It seems the "bug" still persist. Only Blynk cloud open, Chrome is still using about 50% of the CPU resources. And the fan runs... On MS Edge, thing are going a little better with "only" from 15 to 25% CPU usage. M

[marminatix]

Edge same as Chrome. And the fan runs...

[doom369]

@marminatix hello. We deployed the new build with the fix. Please check.

[marminatix]

Testing....

[marminatix]

Hi. The situation is better but not good enough. The CPU usage increases with time and after 30 minutes both Crome and Edge are seizing constantly about 50% of the processor with the "lastest" update rate. No problem with other update rates. Previously, the CPU was seized in a shorter period of time at higher percentages. Sometimes the webpage (always in "latest" mode) freezes and needs to be reloaded. This doesn't happen on the beta android app that remains perfectly updated even in "live" mode. I suggest to assign the issue to someone else too to verify my results. . .

[Peterkn2001]

I've been trying to recreate this and I can't. My chart widget has two datastreams, each set to "AVG of" and I've tested Chrome and Edge individually and together. After a few hours, checking the memory usage at regular intervals I've not seen CPU usage higher higher than 7% and usually it's around 2% or less for both browsers.

Tested with Intel i7-3770 CPU @ 3.40GHz on Windows 10 Pro (64 bit) version 20H2 with 16GB of memory Chrome version 90.0.4430.85 (64 bit) Edge version 90.0.818.49 (64 bit)

Pete.

[marminatix]

Probably I've found the solution. Other than only the CPU over-usage, in the last days, after some device firmware upgrade, the charts began to freeze. Of course I was using "AVG of" and the rate was one per second but in that "one per second" there were 10 Vpin pushed in. So, of course I was an outlaw! And the system was telling me I was.... ;-) While the android beta app (with the same widgets) wasn't affected by the situation, for sure the web page with the chart widget was. This is only an hypothesis but in the last firmware update I reduced the pushing rate of the 10 Vpins from one per second to one per 5 seconds, so now the pushing rate has decreased from 10 Vpin per second to 2 Vpin per second. Now the chrome CPU usage with "lastest" refresh rate is absolutely in an acceptable range around 5%! I was wrong but I needed that data rate level because the units comes out from an assembly line with a pace of some second per piece. Anyway I've solved using the memory of the nodeMCU to store the average values. Thank you all.

[doom369]

Thanks for the update. Yes, 1 req/sec vs 10 req/sec it's a bit different load :). 10 req/sec is not that big that the chart should lag or eat a lot of CPU. Most likely some UI elements are rendered on every request. So this should be fixed anyway.

[marminatix]

Yes. The routine runs with 1 second pace. My fault was thinking it was right but progressively adding Vpins brought the req/sec to 10 and not 1... As you can see I'm not a software developer but I USE these things and I'm sure that tools will help me to improve gathering reliable data from the shop floor, to set the best modeling math for simulating the process and to be effective at the eyes of the customer. I hope the pricing plan would be balanced enough to let us grow together.... M

[doom369]

@marminatix we deployed another possible fix. Please check again.

[marminatix]

@doom369 the rate is at 10 Vpin per second again. Next days I'll have a better situation. M

[marminatix]

After 1 hour. 10 Vpins per second.

[marminatix]

Chart freezed but label working...

[doom369]

@marminatix should be fixed. If not - please create the new ticket.