If you haven't seen this "perspective" yet.... take a look at;
ubus monitor ( while on various luci pages )
If you can find a way to "scale back" frequency or verbosity of the json stream.... ( I think it might be on a js/xhr level ).... you will truly have your finger on the pulse
And at the other end of the equation.... is whether or not the lua ( nixio ) to storage is the bigger bottleneck.
I had been wondering if anything might have changed in inbetween the 17 stable series and the 18, that might have something to do with this?
When v18 first showed up, I and others noticed high load numbers where we hadnt before. And, I seemed to notice lower performance in routing and SQM on my stressed to its limits C7 that I'd been testing heavily. Tried to bring this to attention. But it seemed inconsistent. Not everyone saw it. Nobody was that interested. I went back to v17 last.
Now, I'm trying out v17, v18 and recent snapshots, with the C7's being dumb AP's and a x86 doing the routing and SQM duties. And was seeing occasional high numbers and performance issues despite what should be a much lighter load. But, sometimes no problems.
Clues: seeing 3 (!) lua tasks momentarily appearing at 20-30% CPU each in top, and only when you have a LUCI page open that has some kind of updating going on. I've learned to get off those pages when I run some kind of benchmark.
Edit: have only looked at a recent snapshot, not stable v18.
Suddenly, this makes a lot more sense.
My question, did something get changed v17 to v18 that started this, or made it worse? Does this sound familiar to anyone?
After changing max_requests to 1 and testing for awhile, I noticed that on a device with two radios, the table for the second radio under "Wireless Overview" seems to load information slightly slower. When set to 2 or the current default of 3, all tables seem to resolve from the initial "Collecting data..." state at roughly the same time. This was on a single core mips device, so the effect is probably less noticeable on a newer multi core arm device.
A new default of 2 may provide the best of both worlds with more serialized requests and a less jarring visual experience.
Is there some sort of wizardry you gents can use to "renice" / jail these;
"Clues: seeing 3 (!) lua tasks momentarily appearing at 20-30% CPU each in top, and only when you have a LUCI page open that has some kind of updating going on."
I have run into an issue with this. The Freifunk wizard is set up to prompt the user to put in a password before continuing onto the next step on the install wizard. To know if the password has been set or not, a cgi script is called. A cgi-script runs as root and therefore has permission to look into /etc/shadow to see if there is a password hash (using luci.sys.user.* calls as user nobody doesn't work).
With max_requests set to 1, the cgi script which checks /etc/shadow never gets executed (times out after 30 seconds). This causes the wizard to no longer run correctly. Changing the max_requests to a number greater than 1 fixes this issue.
It may be that some other interfaces in luci have the same issue.
(Finding this thread is the result of countless hours of bisecting the freifunk-berlin firmware with all associated feeds).
I have what I think will be a controversial opinion. I think Luci should be scrapped and that something more like Luci2 should replace it.
It would be nice too, if the instructions for installing Luci2 were updated on the wiki. So that people could test it.
I will mention too that OpenWrt snapshots do not ship with Luci installed, so you likely won't experience the issue if you use one. You will however, need to configure your OpenWrt instance via ssh instead of over http in the absence of Luci.
I'm in the process of writing my own http configuration tool and it's in the early planning stages because of the very issue mentioned in this thread.
@jow I noticed that the proposed fix was reverted. From the commit message, it wasn't entirely clear in which situations we do need concurrent HTTP requests. Could you perhaps elaborate? Would it be safe to keep concurrency disabled if I don't run into any issues with it disabled? Thanks!
this is true, while lowering script requests to 1 does help a bit it is not complete solution and slows down additional radios processing. there is another bug, as even with this change just by overviewing wireless page load on my litebeam 5ac reached 1.60
I was able to improve performance noticeably on my box (less latency and no freezing on LuCI page loads) by switching the SSL library to mbed TLS. Maybe it's just me but mbed TLS seems to perform better on devices with less processing power.