[Help]: Tips to Speed Up Controller

[socal0001]

Controller Version

v5.9.31

Describe Your Issue or Question

From log in to the click on the site, to full load takes a long time. I'm running the docker on a very fast machine with plenty of ram and nvme drives. Are there settings that can speed up the controller? I have tried changing the start up command to '-Xms512m' '-Xmx4096m' and that helped a little. Are there other tweaks to speed things up, please?

Expected Behavior

Snappy controller.

Steps to Reproduce

1. Log in
2. wait
3. Click on site
4. Wait

How You're Launching the Container

'/usr/bin/java' '-server' '-Xms512m' '-Xmx4096m' '-XX:MaxHeapFreeRatio=60' '-XX:MinHeapFreeRatio=30' '-XX:+HeapDumpOnOutOfMemoryError' '-XX:HeapDumpPath=/opt/tplink/EAPController/logs/java_heapdump.hprof' '-Djava.awt.headless=true' '-cp' '/opt/tplink/EAPController/lib/*::/opt/tplink/EAPController/properties:' 'com.tplink.smb.omada.starter.OmadaLinuxMain'

Container Logs

Not applicable

Additional Context

No response

[mbentley]

How are you starting the container is more about the run command or compose file, not just the launch process.

I personally haven’t seen slowness on a system with a ton of RAM, lots of cores, and nvme for storage and I’ve done no tweaking of the configs so that’s not normal.

What browser(s)? operating system for your client? Anything else you can share would help.

[socal0001]

Thanks, I never said thanks. Thanks for creating the Docker, appreciate it.

I use the docker compose file below on a Debian 12.1 VM on Proxmox. The VM has 16 GB of RAM and 1 socket with 8 cores. I'm using firefox on a fast Win10 machine connected to the server over a 10g ethernet. I just tried Chrome without plugins and similar.

Maybe I am being a spoiled brat. In the top right corner, to go to the Organization global and back to Organization site takes about 8 seconds. Does your do that quickly?

Thanks for taking the time to respond, too.

version: "3.1"

services:
omada-controller:
container_name: omada-controller
image: mbentley/omada-controller:5.9
restart: unless-stopped
ulimits:
nofile:
soft: 4096
hard: 8192
stop_grace_period: 60s
network_mode: host
environment:
- PUID=508
- PGID=508
- MANAGE_HTTP_PORT=8088
- MANAGE_HTTPS_PORT=8043
- PORTAL_HTTP_PORT=8088
- PORTAL_HTTPS_PORT=8843
- PORT_APP_DISCOVERY=27001
- PORT_ADOPT_V1=29812
- PORT_UPGRADE_V1=29813
- PORT_MANAGER_V1=29811
- PORT_MANAGER_V2=29814
- PORT_DISCOVERY=29810
- SHOW_SERVER_LOGS=true
- SHOW_MONGODB_LOGS=false
- SSL_CERT_NAME=tls.crt
- SSL_KEY_NAME=tls.key
- TZ=America/Los_Angeles
volumes:
- omada-data:/opt/tplink/EAPController/data
- omada-logs:/opt/tplink/EAPController/logs
- /etc/timezone:/etc/timezone:ro
- /etc/localtime:/etc/localtime:ro
volumes:
omada-data:
omada-logs:

[mbentley]

I don't see anything in particular about how you're launching the container that would specifically be concerning. Have you checked the logs while you're loading the page to see if anything is logged that might indicate any issues?

[mbentley]

Depending on what else you're running on the system that is running the container, 16 GB may not be a lot of RAM. Have you checked to see how your current CPU and RAM consumption are across the system while the controller is running?

[mbentley]

Looks like mine takes about 3 seconds with just one site + global.

[SP3NGL3R]

Whoa. I just upgraded to the latest (I upgrade every week with your releases ... crazy how often you release, congrats) and I'm suffering the same. My pages are now taking ~15s (via developer tools) to finish. I had a snappy UX before too. Something's changed for sure. I'm offering 2 cores of my i7 and 750M RAM to it. That 'was' plenty before.

[mbentley]

With Safari or another browser? I'll say that 750M of RAM isn't a lot for the controller. I allocate 4 GB of RAM to my controller and it has used a peak of about 2.5 GB of that RAM. Since there's a MongoDB in addition to the Spring Boot Java app, you're going to see the best performance with more RAM allocated. Also, I assume you're updating the default -Xms128m -Xmx1024m values from the CMD?

Yeah, I've automated all of my builds and builds occur any time there is a fixable package vulnerability (or a manual change that triggers a build).

[socal0001]

I've added a line to docker compose show below. The only changes I made were as follows, "'-Xms1024m', '-Xmx4096m'". Any suggestions for optimizing the "command" for speed. I could allocate another couple of GB if needed, I prefer snappy if not crazy resources. Even with these settings not nearly as snappy as used to be. [Obviously this is not your fault, just curious if you have a minute.]

command: ['/usr/bin/java', '-server', '-Xms1024m', '-Xmx4096m', '-XX:MaxHeapFreeRatio=60', '-XX:MinHeapFreeRatio=30', '-XX:+HeapDumpOnOutOfMemoryError', '-XX:HeapDumpPath=/opt/tplink/EAPController/logs/java_heapdump.hprof', '-Djava.awt.headless=true', '-cp', '/opt/tplink/EAPController/lib/*::/opt/tplink/EAPController/properties:', 'com.tplink.smb.omada.starter.OmadaLinuxMain']

[mbentley]

@johnthomas00 - as long as you've allocated enough memory, that should be fine. I haven't added any specific optimizations at all to the java arguments so I don't know if there are gains to be had - the default run command basically just uses the java args from the controller's init script TP-Link ships as I figured it makes the most sense to stay close to what they do. I run the default of -Xms128m -Xmx1024m on mine.

I hope that they move to Spring Boot 3.x before too long as that should also help with performance. At least on amd64 and arm64 for versions >= 5.4, it already uses OpenJDK 17 JRE which already provides some performance optimizations out of the box over OpenJDK 8 JRE.

[ovizii]

I am using your image with the 5.15 tag.
I like to give my containers certain boundaries with the below commands.
What is safe for your container? I haven't touched any of the Java commands mentioned above. I simply want to know, if running your container with defaults, what are its requirements in terms of RAM (your best guess is good enough)

    cpus: 1
    mem_limit: 2G

[mbentley]

I run the standard 5.15 tag, no JVM arg tweaks and with the following docker run cli args:

...
--cpus 2 \
--memory 3g \
--memory-swap 4g \
...

CPU isn't a problem at all, I'm sure I could drop it to 1 CPU; at worst, it might slow down startup but I haven't tested. Over the past 30 days, here's my CPU metrics:

And for memory, it's peaked at 74% memory utilization: