+1 Luci causes the system to be overloaded！
Is this also seen with nginx?
The default in 18.06.2 is in fact 1, so someone clearly thought it a good idea.
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).
Related freifunk-berlin commits and issues:
Here is a picture which helps to explain part of the problem:
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.
1 Like
You can take a look here: https://github.com/obsy/packages/tree/master/easyconfig
Check the performance is it what you expect . You can use https://translate.google.com/ to translate the page http://eko.one.pl/?p=easyconfig
@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 still got the issue using Davidc502 latest build and the WRT32X with option max_requests '2' in uhttpd in /etc/config.
It is much better with option max_requests '2' but i still get the issue 
Also i am using dnscryptv2, but even without i got the issue.
Any other trick?
Try:
uci set uhttpd.main.http_keepalive=0
uci commit
/etc/init.d/uhttpd restart
3 Likes
i think it's fixed. Thank you sir.
think it helped mine too.
1 Like
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.
1 Like
thanks this helped me !
Yeah, it's kind of in the name "embedded TLS library" 
I guess I should have clarified, mbed TLS seems to work better on my ar71xx devices than my mt7621 devices, and the OpenSSL seems to work better on my mt7621 devices than mbed TLS.
1 Like
Aaah! Your mt7621 device likely has a built-in crypto engine.
1 Like
Thank you, it works.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.