Long running trend scripts - b3084

[stevendt]

Hi,

the trend zooms in the latest version (b3084) seem to take a long time to pull the data. I got a message from Edge about a long running script, but most times, the trend redraw is just really slow, has anyone else seen this behaviour?

UPDATE : It appears that it's just Wind Direction that has this, other trend response looks normal

regards
Dave

[mcrossley]

Nothing has changed in those scripts for some time - only the highcharts theme has been pinned to it's old source.

What sort of computer are you running the browser on? The wind direction chart does use some custom code to plot the points in HighCharts which is quite expensive in compute time.

[stevendt]

Hi Mark,

thanks for the reply, I first noticed the issue on an iPad using Safari, but have the same problem on two laptops running Windows 10 - one of which is very powerful.

Could you have quick browse to the Wind Dir trend at http://primrosebank.net/weather/cumulus/index.htm and see if you see the same behaviour when switching timebases please?
If you do, could it be some sort of data corruption?

More Info: I just tried Hans's site at https://meteo-wagenborgen.nl/
Switching between All and 12h for Wind Direction (Windrichting) takes an age (it's all relative I suppose, but 10s feels like an age ), is that to be expected ?

regards
Dave

[ConligWX]

both trend zooms from my pc to those two websites are working fine. perhaps you have some issue with your broadband, browser plugin, or AV slowing the screen down.

[water01]

I tried it on your site and then on mine and yours is way slower, whereas mine is almost instantaneous. Ran the Developer pane on your page but there is nothing obvious.

[stevendt]

Hi Simon,

thanks for the info. If you can zoom the Wind Dir trend without undue delays, then, yes, it must be something here, but, unless it's some weird internet connection thing, I don't know what it can be.

Tried different computers (3), plus iPad
Different Browsers (Edge, Chrome, IE and Safari)
Different AV (Norton, Symantec SEP)

mmm, puzzled

regards
Dave

[ConligWX]

you could tried enabling compression on the json files and and possibly adding leverage Browser Caching some files perhaps?

https://gtmetrix.com/reports/primrosebank.net/uYsUQxi5

in your .htaccess file add

Code: Select all

  AddOutputFilterByType DEFLATE application/json

to the </IfModule> section.

[stevendt]

Hi Simon,

thanks for the info - that's an interesting diagnostic page - not that I understand much of it

Is .htaccess not an Apache web server file? I think that my host is using IIS

I think the equivalent might be web.config (?), but there's no equivalent looking section in that file

regards
Dave

[ConligWX]

Sorry, cant help with IIS i'm afraid. Yes htaccess is Apache.

[stevendt]

Hi David,

thanks for trying, and the feedback. Did you try the other link to Hans's site? - IS it the same?

I just tried on your page and get good results too - I guess that rules out my browsers and internet connection and it's something in the config/data

regards
Dave

[HansR]

Hi Dave,
If I may jump in the discussion. If I understand it well your problem is the slowness of the graphs, especially when loading and when switching times base (6hr 12 hr and all)

• the difference between your site and my site wrt the graphs does not exist. The graphs are the same, the software is the same.
• the graphs are made by HighCharts javascript procedures, and the data is loaded by Ajax-calls.
• Any slowness must be analysed by data loading or rendering of the graphs.
• If I look at your site, I see no slowness. But if you experience slow behaviour it must be somewhere in your environment. As your Win10 laptops also behave slow (correct me if I am wrong) I have a question: are all machines displaying this behaviour on the same [local] network?

[stevendt]

Hi Hans,

thanks for jumping in (I hope you didn't mind my using your site as an example?).

The machines here are all on the same local network (domain).

The situation is very confusing, you graphs and mine are very slow for me, but . . .
David's page works fine, but he sees my data refresh being slow
You see my page working as expected

There does not seem to be consistent behaviour between different users looking at different sites when looking at the Wind Direction (not speed) trend

regards
Dave

[HansR]

thanks for jumping in (I hope you didn't mind my using your site as an example?).

You're welcome and no I don't mind at all

The machines here are all on the same local network (domain).

The situation is very confusing, you graphs and mine are very slow for me, but . . .
David's page works fine, but he sees my data refresh being slow
You see my page working as expected

There does not seem to be consistent behaviour between different users looking at different sites when looking at the Wind Direction (not speed) trend

No it does not seem consistent, however as your site behaves normal to me and you have problems within your local network and my site looks slow to you as well , I would really suspect your network. I would start try rebooting the router/switches or whatever hardware you have and if that does not have any effect, try at the neighbours on their local network if that is possible.

These graphs are network based although it is unclear to me what the event behind the rangeSelector (6, 12, all hrs) does. But it would not surprise me if it had something to do with the local network. So I would try a reset there first.

[stevendt]

Hi Hans,

I can't reset my router and switches at the moment, but I think that I have eliminated the local network. . .

If I disable wifi on my iPad and connect to the web using 4G, the results are the same - the Wind Dir trend is very slow, so I think that suggests something at my web server (hosted) end.

Edit: just to be clear, it's not necessarily the initial call up of the Wind Dir trend that is the problem, it is when I select one of the zoomed time ranges (6h, 12h) that the graph takes an extended time to display after it runs the associated script

regards
Dave

[HansR]

Edit: just to be clear, it's not necessarily the initial call up of the Wind Dir trend that is the problem, it is when I select one of the zoomed time ranges (6h, 12h) that the graph takes an extended time to display after it runs the associated script

If it is the rangeSelector, than it is in the Highcharts/javascript subsystem. What I said before, I am not sure what the event handling of the button press of that selector does, but I assume it simply uses the data it already has and recreates the graph. I tested this locally here and I don't see any network activity by pressing the range selector.

So, it points to the Highcharts/javascript subsystem, but I would not expect it to be similarly slow on three different machines.

Unfortunately, it ends here for me as well.
Still I would try some reboots of routers etc...

Anyway, if you are handy with the browsers you might try the debugger/console/network/performance analysis methods, otherwise this could be difficult to troubleshoot.
Sorry don't know.