Real time graphs, connection page issue

Hi, I'm wondering if anyone else is having problems with the Connections page in Real-time Graphs?

In 18.06.1 it did not work for some time and stopped on collecting data, until a few months ago when I did long overdue opkg upgrade of upgradable packages and it started working again.

So I have now upgraded to 18.06.2 and the page just seems to run slow to the point of the browser timing out or giving errors about slow scripts. The user experience is connect to the page, couple of seconds of collecting data, then the graph comes up but only a small percentage of the connection data. Following this the browsers (multiple systems and browser types e.g chrome, Firefox etc.) freeze or gives an error, sometimes it does populate more data and occasion gets the DNS resolved, but by this point scrolling up and down on the browser seems impossibly slow or frozen to the point that I have to close it, re open and login.

There is nothing in the syslog that ties in to this from what I can see either router or client side for the browser, just the on screen errors that seem to point to a slow script and this has only happened since the upgrade.

So any ideas regarding possible fixed appreciated?

This is running on a Linksys WRT1200ac hardware wise.

Thanks in advance.

Paul

Try max requests 3 <> 5 and see if that makes a difference.
There is a gui option for this on master... not sure about 18.06.2 ... check on the last tab near the timezone setting.
/etc/config/uhttpd

option max_requests 5

and for brevvity

/etc/init.d/uhttpd stop
rm -rf /tmp/luci-*
[ clear your browser cache  not really needed here but useful with most luci stuff ]
/etc/init.d/uhttpd start

Thank you for the above but after changing the above to 5 and even to 10 and completing the stop, clear and restart command's I still have the same issues. I have also tried put max connections to 200 as well, but still the same issue.

However I have done some further testing and is seems to be number of lines and the auto refresh that is causing the issues. Typically I have high hundreds of connections and if I turn systems off and get this down to around 100 it gets more responsive (even with the setting at 3 and 100 connections) but not normal. If I turn off auto refresh, it immediately goes back to the old pre-upgrade and normal level of responsiveness I can scroll up and down without issues. Turning auto refresh back on brings the issues back and also as the data lines build it slows more and more and back to the original level of issues.

ubus -M r monitor

test with these off in /etc/config/luci

#config internal 'ccache'
#	option enable '1'

#config internal 'apply'
#	option rollback '30'
#	option holdoff '4'
#	option timeout '5'
#	option display '1.5'
/etc/init.d/uhttpd restart

also... you might have to ps kill any browser processes while your testing ( between tests ).... there are known issues with rogue chrome calling in the background.

How many connections would you estimate are open at the time you browse to the page?

1,000...2,000...5,000...10,000???

@lleachii - when the issues were really bad to the point of having to close the browser, there was 900-1200 connections listed. Currently I have 140 connections and the page comes up but scrolling is very jerky.

@anon50098793 - I don't have a "config internal 'apply'" section but have commented the other section out and restarted everything with the ubus monitor turned on. Nothing is shown re the problem webpage in the monitor from what I can see, experience at around 140 connection is as above slow and jerky, I managed to get up to around 500 connections and it was noticeably more sluggish as the connections ramp up.

I have tried adding the missing section in to the config file and restarted uhttpd but it does not seem to make and difference.

Looks like I was on wrong track... make sure you undo those...

Seems related maybe to ip/dns then? What is the ip6 / dns environment like client <> router?

OK...1,200 is quite a bit for the GUI on some devices...but your CPU and memory should be able to handle that.

Realize that on the GUI, your device is doing a nslookup for all the IPs listed (2,400 IPs).

Perhaps slow DNS responses?

SOLVED - While looking at the DNS set-up as mentioned above as I use DNSCrypt I noticed that ping times to Google on the wired network was mostly 15 to 30ms, but for Wi-Fi was 100ms+ and sometimes out to 500ms+ when under load. So I went through the setting in Wi-Fi and some settings seems to have been lost, I assume in the upgrade? Both the RTS/CTS Threshold and Fragmentation threshold were blank on both radios (2.4 and 5Ghz), I thought that blank would mean run at default which typically are 2346, I think that this kind of turns it off as the threshold should never be broken. However, this default does not seem to be the case as when manual typing and saving the 2346 in these fields (on both radios separately) the ping times are now the same as wired (15-30ms), the Wi-Fi seems more responsive and the issues I had with the page which was on Wi-Fi connected devices are gone and it's working as expected.

I can only assume that rather than the page or the script being at fault, it was the wireless network in between.

As a side benefit to this, my children's Fortnite game that has had high ping times of sometime up to a 1000ms on the PS4's, has run all afternoon at less than 50ms pings, which I believe is good and allows them to shoot things...

Thank you for the help and pointers...

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.