[Help]: Omada Controller stupidly slow #482
Answered
by
fpoussin
forgenator
asked this question in
Help
-
Controller Versionv5.13.30.8 Describe Your Issue or QuestionI wrote in OpenJ9 feature issue about my ongoing issue with Omada Controller being reallyreally slow. So I figured, I will try to get to the bottom of this, maybe people have ideas, maybe I'm doing something I shouldn't. Or maybe nothing comes of this. Expected BehaviorI would expect omada controller to be snappy, page loads happening in seconds and it being a happy running software, instead, when i load my organization frontpage, it takes 14 seconds to load. All the UI is really sluggish, and I'm at a loss of what should I actually expect. I always thought, it was just Omada being slow, but maybe it's not? Steps to Reproduce
How You're Launching the ContainerContainer LogsMongoDB LogsAdditional ContextI'm running omada controller on RaspberryPI 5, with 8GB of RAM. I did a network scan using firefox, and when loading the organization front page, and it was staggering:
In my frontpage i have these widgets:
Yes, i'm running omada behind traefik, but it hasn't made the issue any prevelant or modified it in any way, it just gave me nicer hostname to run omada on, without port suffix. |
Beta Was this translation helpful? Give feedback.
Answered by
fpoussin
Apr 4, 2025
Replies: 4 comments 8 replies
-
|
My docker stats for omada controller: When I load organization frontpage, the CPU shoots to maybe 15% and then goes back down to 2% or less. |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Just some page load time data for comparison: I loaded my home organization page without any cached data (disabled via dev tools) on a hard page refresh and here is what I see: With page cache and a hard refresh: With page cache, no hard refresh it's a little bit faster: And just to verify a few things:
By the way, you either have a copy/paste error or a typo in your autobackup directory location (double |
Beta Was this translation helpful? Give feedback.
4 replies
-
I will test running this on my other machine, which is amd64, and see how it fairs, maybe it's faster, and i will migrate my setup there, but the rasp5 i have, is hosting all my mission critical software, so it's more like separation of concerns, where i would like to keep omada there. It could be, that I have some funky setup problems with my rasp, but that sounds far fetched. I will report once I have tested running on another machine. |
Beta Was this translation helpful? Give feedback.
-
|
I did notice, now that, once i start my omada controller, it basicly utilizes only once core, and it will hit 100% and then it will go back to idle. If this gives someone any ideas. And the problem is, everything else is running flawlessly, like really really fast. But for some reason, this just isn't. I'm running latest debian, latest eeprom and everything should work flawlessly. |
Beta Was this translation helpful? Give feedback.
-
|
Okey, i just did something stupid, and tested it with chrome, and everything is really really smooth. So it's a firefox problem, not omada problem, or my server problem. Which sounds really really weird, but the same omada is really really usable on chrome, but not on firefox. |
Beta Was this translation helpful? Give feedback.
-
|
Well that's odd. I use Firefox (well, Librewolf actually and I have used Firefox itself in the past) myself and I don't see performance issues. I had seen reports of Safari specific performance issues with the controller but had not heard about Firefox being an issue. Not sure if you have container tabs enabled but I'd be curious if you see the same performance issues in a new container tab where you're starting from a clean slate - no cache, cookies, etc. |
Beta Was this translation helpful? Give feedback.
-
|
Hey, I don't know how relevant is it but I have the same issues with 5.14-chromium image and firefox / midori. Midori without cache (but with cache nothing changes). firefox is 2 sec faster (wow) I also tried to load it with edge and this is the result: |
Beta Was this translation helpful? Give feedback.
1 reply
-
|
So it looks like a similar situation - rendering on a Gecko (like Firefox) based browser is slow but a Chromium based browser is much quicker. |
Beta Was this translation helpful? Give feedback.
-
|
Are you using the "dark reader" extension by any chance? |
Beta Was this translation helpful? Give feedback.
3 replies
-
|
This! Turned it off and everything was smooth again. |
Beta Was this translation helpful? Give feedback.
-
|
This fixed it for me as well. Note: Just disable it for the domain or IP you are using, the extension can stay active. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you! I was having the same issue, turning off dark reader fixed it immediately! |
Beta Was this translation helpful? Give feedback.
Answer selected by
mbentley
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Are you using the "dark reader" extension by any chance?
That was the issue on my side (using Brave).
Firefox works just fine as well.