Console Output in Web UI (Workbench) CPU load in web browser increases noticeably for fast or long output

Found nothing related in forum search. Maybe this is already known. But I wanted to at least report:

This is just some scrolling text. Nothing that should overwhelm a contemporary web browser.

It seems to also have a mechanism of not keeping the entire log, but throwing older rows out of its buffer (e.g. only keeping the newest 1000 lines).

Something in that JS implementation of a console window in this Web view is not optimized. That's what I'm reporting.

Ok, this limitation is accepted then:

• If one has constant high frequency console output, then better only watch max 1-3mins, then close the browser window.
• Then there is currently no way to return to an open session.
• Returning to Services > USB Backup later only shows the list of existing jobs.
• You can enter or run another instance.
• But not re-enter into a running one to observe it.

One idea (if feasible) to still make the best out of the given framework:

• The overview shows a "running" text/icon near running backup jobs.
• Hovering over that running text/icon, shows a hint "show progress", which if clicked takes you into the detail window again, where it re-initiates the log (starting the output that standard-out of the running process produces at this very moment).
• Then you can reinsure yourself about the progress.
• Watch 1-2mins again at most not to get the web browser too stressed.
• Then close the browser window again.

As written. Just an idea. If too much work it's ok as-is for small to medium console output amounts.

• Everyone who wants to observe a massive or long output has the workaround to monitor via SSH.

Given your post a second thought:

Zitat

Updated from a temporary file in /tmp/.

And because the file may change due to how some commands output, the browser window indirectly (through php) reloads the entire file.

That may explains it B/c usually those JS framework (like Angular or React) manages this DOM / shadow DOM really efficiently, and process 10k of objects.

But the way how that temporary intermediary file is written and loaded may indeed be the problem. Only usbbackup uses that /tmp output file, or all apps which use the console output mechanism in the Web UI?

Ideal: The temporary file is chunked into intermediary chunks (as common in the video streaming context).

(That chunks don't need to be own files necessarily. Cam also be in the same file, and just a line-number-pointer makes sure that the correct (=non-overlapping chunks) are loaded.)

Simplified scheme:

• chunk1.txt: 12
• chunk2.txt: 34
• chunk3.txt: 56
• ...
• The JS always loads only the newest chunk, and keeps only N old chunks (so that you can scroll back a little)

As it is now (maybe) Simplified scheme:

• tmp.txt at t0: 1234567
• tmp.txt at t1: 12345678
• tmp.txt at t2: 123456789
• tmp.txt at t3: 234567890 
• tmp.txt at t4: 234567890a
• tmp.txt at t5: 234567890ab

So the browser loads the same stuff over and over again, and only minimally new stuff and maybe only minimally the old stuff gets removed from tmp.txt. Is this happening?

I wrote "drastically/exponentially" as I only loosely observed this, and not scientifically/methodologically.

Linear growth of a memory flowing full is also enough to get to a stall finally.

Sorry if this was over alerting language. Corrected it in the title to "noticeably" and even the annotated screenshot.

Everyone who wants to try to reproduce this.

Run a USB Backup with a significant amount of files (for a test you can create 100k folders / 1M mini files with a loop if needed).

And observe your web browser as it displays the ongoing console output for it.

geaves

• OMV is a voluntary open source project. I expect nothing.
• If the above is deemed of zero importance, then just drop it. No harm done.
• I had written "an idea" and "everyone who wants to try to reproduce".
• In case anyone has interest to improve that particular part. That was all.

ryecoaaron

• If all affected by this, then maybe an incentive to look at it.
• Again trigger warning: I write purely in conjunctive. I expect nothing. I do not want to stress anyone. Just reporting.

I now receive your message:

• I should already better pre-filter what I post about as a first measure of respect. Will try to better follow that.
• Per each new community one joins, you have to get a feeling of what's desired, appreciated and adequate there, and what better be left off.
• I was a slow learner in that regard here on OMV 😉
• Now that recent messages were clear in that regard. Getting silent now.

Independent of the performance issues:

Would it be possible to start a potentially multi hour script such as USB-backup, close the browser, and hours later return and jump into the log session, which you started?

This is a valid mainstream use case. You have a NAS to do the heavy lifting, and leave your other devices unaffected. Having to leave i.e. a laptop running, just to observe the process is not very convenient. Would be cool if you could detach and reconnect to the log output of a running job instance.

What I do for now is trust it blindly (closing the web browser) and when coming back later observe it indirectly: USB HDD LED flickering, Shell: /var/log/rsync.log or iotop to see whether high I/O or fatrace to see filesystem activity. To know whether USB Backup completed and I can detach my HDD safely.

What file is supposed to be in /tmp during a running sync?

What I found is that during a running sync theres /srv/LONG-UID and as soon the job is done it is not there anymore.