Unusable UI

[Borja Marcos]

Any hint on when might it be solved?

The UI is unusable. I have spent 30 minutes trying to edit the permissions for a dataset (I have 100) and the browser just freezes.

I have about 80 datasets under a dataset called "Homes". When I try to access the listing of datasets under "homes" it gets worse and I am unable to open the menu for any of the datasets. Even the row highlighting when the mouse runs over the datasets stops working.

Maybe it's a problem with the huge syslog spam from Samba on the bottom mini console, I am not sure.

 

[Patrick M. Hausen]

I would try disabling the mini console first. Does that help?

 

[Borja Marcos]

Now comes que silly question (sorry!)

Is that possible? I have been looking for a setting and I haven't seen it.

 

[Borja Marcos]

Scratch that, sorry! For some reason I didn't see it. Now I've disabled it, testing.

 

[Borja Marcos]

And no, it doesn't help at all. I assumed that would be consuming a lot of JS resources on the browser.

So, no idea. Maybe it's just the UI is refreshing information too aggressively... I am still unable to edit the bloody dataset permissions. :/

 

[Patrick M. Hausen]

 

[Borja Marcos]

Yes. My apologies, for some reason I had failed to see it.

 

[Borja Marcos]

OK something interesting.

Maybe it's only a Macos X problem? Turns out I have a console window with a ssh session on a server, and I am compiling bind on it. So there is a lot of text output (different process, not Safari).

Hiding that terminal window has made it much easier, now the interface works much better.

Still: is the TrueNAS UI too resource intensive? I don't know how it works, but if there is some "frame rate" setting I think it's set way too high. On older computers it might be a serious problem.

 

[Patrick M. Hausen]

Sorry, no idea. I am on Mac OS, too. Sometimes the UI is a bit sluggish but that is mostly in the "jails" section and I guess it is calling iocage externally and I know iocage can be slow collecting all the information ...
But apart from that. Works ... *shrug*

 

[Kris Moore]

@Borja Marcos Pointed our UI devs at this thread for investigation. Thanks for letting us know its not behaving properly on your system.

 

[Damianos]

@Borja Marcos Are there any errors in your browser's JS console?

 

[Borja Marcos]

@Borja Marcos Are there any errors in your browser's JS console?

Ok, sorry for my somewhat fuzzy "report".

In a previous message I said that disabling the mini console didn't help but there was actually an elephant on the desktop: a terminal window with a ssh session to a server and a lot of scrolling activity.

Trying to elaborate more now. This might be a compound issue.

First, performance. This might be mostly a Macos problem, as it has an Achilles' heel: heavy text scrolling. So, yes, disabling the mini console shows an improvement. The browser seems to suffer a lot when there is a lot of heavy text scrolling, be it the mini console or a terminal window on which am compiling stuff (note that the compilers weren't running on my Mac, but a remote server).

Second and UI related. Doing a test, I noticed something really wrong. After connecting to the UI and disabling the mini console I still had problems with the storage section. However, if I started the browser and I connected to the UI with the mini console already disabled everything worked better.

So I have done the following: Connecting to the UI with the mini console already enabled and disabling it. If after disabling the mini console I start a tcpdump I still see lots of mini console refresh messages coming to the browser. I don't know whether the UI server is still sending previously queued mini console messages (which won't be shown on the browser because the mini console widget disappeared when I disabled it) or there is a bug and once I have started a UI connection with the mini console enabled messages will keep coming.

In any case there seems to be a problem related to the mini console. I insist, it may be a Macos specific problem, but mini console messages should stop reaching the browser when the mini console has been disabled. They keep coming.

Even if they are just queued somewhere, that queue should be destroyed/emptied when the mini console widget is disabled. And if they keep coming despite disabling the mini console because they were piling up due to the browser being unable to keep up with them there should be some mechanism to discard them, a "low pass filter". There is no reason to insist on filling buffers.

Maybe this is related to the problem I noticed?

If the UI is too resource greedy in my opinion it should be reviewed. What happens if you are managing a TrueNAS remotely using a connection with poor bandwidth?

I will try to do a more comprehensive check looking for Javascript errors, etc.

Summarizing for now:

- I think the mini console is a problem. Either because an actual bug prevents mini console updates reaching the browser after disabling the widget or because a reliable transport policy forces the browser to receive all of the mini console widgets even when it's not able to cope with the load.

- I would suggest the developers to rethink the logging policy. Maybe a simple threshold for the mini console, separated from the general syslog threshold would suffice. For example, I think it would be very useful to be able to send detailed Samba logs to a SIEM but those detailed logs are a catastrophe on the mini console.

- I wonder, is there anything special about the Storage->Pools section that makes it more prone to browser performance problems?

I'll keep checking.