Device: iPhone
Browser: Safari
Benchmark time: 3.0 ms
RAM: -1 GB
CPU cores: 4
Slow device: Yes
2 Likes
Thanks @Steini! Iāve fixed the test, so 4 CPU cores shouldnāt be considered slow; only devices with fewer than 4 cores should be. So, in your case, it should say āNoā for āSlow deviceā column.
Benchmark time: 33.0 ms
RAM: 4 GB
CPU cores: 8
Slow device: No
Test on Samsung J8 with Chrome browser.
Benchmark time: 65.0 ms
RAM: -1 GB
CPU cores: 8
Slow device: Yes
Test on Samsung J8 with Firefox browser.
Thanks! But do not do Firefox browser, try Chrome or Edge.
1 Like
Wait, can you run this instead?
1 Like
Device: SM-J810F
Browser: Chrome
Benchmark time: 42.2 ms
RAM: 4 GB
CPU cores: 8
Slow device: No
Device: MAR-LX1M
Browser: Chrome
Benchmark time: 33.9 ms
RAM: 4 GB
CPU cores: 8
Slow device: No
Tested with another phone.
Look, thatās confusingāIām not sure how to handle it. Just out of curiosity, what Android version do you have installed?
The only best solution for you is to create a separate Webmin user for mobile use with live stats disabled.
1 Like
Android version: Android 10 (One UI 2.0)
Thanks so much, Ilia ā I truly appreciate the time and attention youāre giving to this issue.
Your suggestion to create a dedicated Webmin user for access on low-end devices, with real-time monitoring disabled, is a very smart and elegant workaround. It effectively solves the performance problems on lower-end devices and is a great solution for now.
Also, the benchmark test idea was helpful ā the results can still give a general sense of a deviceās capability (for example, a delay below 20 ms on a device with at least 4 CPU cores may suggest a reasonably powerful system). But overall, I understand and agree with your point that a proper solution requires broader and more context-aware logic.
I really donāt like this benchmark idea. Thatās abusing user resources and chomping up battery life.
Just default to not doing heavy stuff on a small screenā¦hide those graphs behind a button or whatever and the user has to explicitly choose to load a realtime stats page, instead of having to pay the price always.
1 Like
Yeah, sure thing, I wasnāt going to add this. Though, itās not resourceful or abusive in any way. Itās just unreliable.
Iām not sure if we should, since it seems to be a one-user issue. In that case, the solution is to create a separate Webmin user login with different settings for a low-spec mobile device.
1 Like
Have you added a swap disk? It can make huge difference on a low RAM system.
I have 1gb swap disk, which I thought would have been enough, but as this is a different problem to the original one I may open a new thread at some point
Well thought I would give it a try.
no idea why but all I get is a blank screen that eventually seems to redirect to virtualmin/docs, hey but as I said, it is an old J8 with most things blocked (over the years) no idea what android version is running. it only is used for sms and as a ābrickā phone only a couple of apps
1 Like
Device: Unknown device
Browser: Chrome
Benchmark time: 5.8 ms
RAM: 8 GB
CPU cores: 4
Slow device: No
Device: SM-S928U
Browser: Chrome
Benchmark time: 15.9 ms
RAM: 8 GB
CPU cores: 8
Slow device: No
Thanks for sharing! We wonāt use this approach to solve the problem.
The most likely solution is not to send data over the socket in mobile mode unless a user is on the dashboard or has a large enough mobile screen for the right-side slider to stay fixed. Data from the socket updates it tooādid yāall know that? 
ā¦after checking the code, thereās room for improvement. I originally made it simple, pausing socket communication if the page isnāt visible or not focused. If we didnāt need to constantly update the right-side slider, which is functioning as a small, always-available dashboard then we could just open the socket when the user visits the main dashboard and close it afterward. But since we need to update the slider, itās not an option.
Iāll try to fix it as described and will update this ticket with the progressā¦
1 Like
This feature has been implemented! From now on, we wonāt send any data over the socket a few seconds after the dashboard page is left or the right side slider is closed. Weāll also pause socket communication if the page isnāt focused.
@asadister Give it a try with the latest Webmin development version, and let us know how it goes for you.
1 Like
Hi Ilia,
I just tested the latest development version of Webmin (2.402-dev) on my server with real-time monitoring enabled.
Itās behaving erratically now, sometimes smooth and sometimes slow, this is most noticeable when opening menus.
If thereās anything else I should test, let me know.
Thanks!
The theme behaves predictably. Itās in fact as accurate as it can be.
Iām not sure what you mean by āmenusā. Though keep in mind that socket communication resumes when:
- The dashboard is visited
- The right side slider is opened
After you leave the dashboard page or close the right side slider, the system waits about 5 seconds before pausing socket communication.
If you want to test if socket communication affects performance on your low specs phone, avoid opening the right side slider or dashboard, and then navigate through the pages of Virtualmin or Webmin.
Remember that by default, when you switch between Virtualmin and Webmin, the dashboard opens, which restarts socket communication.
Simply put, socket communication restarts in about 300 milliseconds after visiting the dashboard or opening the right side slider and takes about 5 seconds to pause again after theyāre closed.
1 Like