Add a filter glyph that allows the user to automatically show/hide columns in a table

[cigamit]

This way we can have more columns displayed by default and allow for some preferences by user across all tables. I was thinking of a cog plus jQueryUI dialog. And then the real decision is do you do all this in jQuery or carve an option into the tables. It's another reason to resurrect the old table class that was written by @TheWitness years ago.

[netniV]

I like the idea of the jQuery because you can then show and hide columns pretty quick without refreshing the data. However, it does also mean you've got to send everything then only show what you want.

[cigamit]

Only downside is that when you have 1000 rows, the rendering itself becomes the problem. Just try that. Goto something like the Data Sources page where you have a lot of rows, set the row selector real high, and then resize the page. We are already doing it to be responsive. Just need to adapt it, add a callback to save the columns to show/hide, and then update using the updated column hiding code.

So, since we already are using that method, let's do it entirely in jQuery.

[stefanbrudny]

Hmm, can we vote for this?... Spine have never been a blocker, this is real blocker for performance and weakest point of the whole app, as it breaks so badly it destroys any of my servers...

This is NOT ranting:

• please add 100k devices to your installation and try to change single setting on all of them
• please try to select 20k devices out of 100k and try to determine on which the change has been successful
• please try to not run out of RAM when you try to display 30k devices in your browser trying to segregate and find a pattern in devices
• try to sort the devices by a property
• try to find a device which does not match to your pattern

Literally, impossible.

[netniV]

I would agree, even on small systems, if your hostname is particularly long or another text-based field has a long value, it can hide other details you want to see. I think one of my own first issues that I raised was the interface descriptions causing pretty much all other fields to be hidden.

There are plans to change the method of generating the tables, so this is pending on that work.

[cigamit]

Just a few comments. There was a reason that we reduced the select list to ~500 objects from the various pages

• Due to the PHP memory requirements to process more than that on the backend. We have found that to operate on as many as a few thousand objects causes a very large spike in memory, to around 800MB+ (in PHP5.x versions, much less in PHP7.x versions).
• Additionally, due to on page JavaScript, rendering more rows had a detrimental impact on page performance due to both jQuery and jQueryUI event propagation, column sizing, etc.
• Max post size, which we had overcome in the past.

Some of these issues are inherit in browser based applications. The memory issue though seems to be related to the PHP PDO/MySQL modules, though the amount of memory consumed starting in PHP7.x seems to be way down, less than half of the PHP5.x series.

I would suggest that if you wish to have custom pages that allow more rows, that might be better suited for a plugin as the framework, be it jQueryUI or bootstrap, will have the same issues with 30k rows where not so much JavaScript is in use.

So, in the end, I agree that it would be great if we could support that many rows, and maybe one day we can, but right now, with JavaScript enabled, it's going to be real difficult.

[cigamit]

Also, we have planned to allow for showing/hiding columns. We just have not gotten to it.

[netniV]

One thing I have wondered especially when talk about scaling with the Cacti JS, should we reduce the number of anonymous functions being added/removed from tables etc:

https://stackoverflow.com/a/80927/697159

[stefanbrudny]

@cigamit yes, the memory problems are exactly what bugs me a lot. I was never able to crawl my list of devices and again, had to use SQL for nearly all action.

But lets pretend I do not understand this all stuff, what the heck PHP and 800mbpipes is, anyway?... An user have to retain a possibility to maintain the devices and change some values in bulk. When in thousands, it becomes impossible.

No. Number of devices displayed is not really a problem, it could be decreased to even 50 by default. The problem is the way of executing Actions for devices (changes to the devices configuration). Cacti tries to suck the whole list of devices, potentially 6 digits number. THis approach is OK for 50 devices, but it looks silly when processing more than several k of devices.

User do not care whether this action takes 1 minute or 1 hour, as long it is in the background. Can't these actions be schedule for ALL devices matching the selected search options (this is why it is so important to have much more options for selection)?

This would be nearly an next level for devices maintenance. Fire and forget, it is done in the background. Having an entry in poller log with a progress, would be nice addition, though...

This could even be set with own pace in Cacti poller (eg. change is done for 10k devices every minute only).

I am not saying interfaces and output data should be displayed in list of devices, user need only all device properties. Well, if the description is in multiline, than let it be. Just allow an user to show/hide the column.

[netniV]

That requires a complete separation of UI from business logic and is something we are trying to move towards. However, that’s a lot of work involved especially testing all scenarios of single/multi poller plus the front end, and cli.

The problem is that most of the code was written without that level of separation.

It’s a long term goal that’s going to take a while to get there without a big influx of assistance.