When searching the tree, increase the time before querying for items

[dkuji]

Hi.
We are running a very large Cacti server. (Devices: over 1,000, Graphs: over 14,000)

OS: RockyLinux8.6
Cacti: 1.2.21
CPU: 12core
Memory: 32GB

It takes a very long time to search for a graph by entering a tree name or graph name from the Graph tab screen of the WebUI. (More than 100 seconds, I have confirmed that I have enough cpu and memory at this time).

However, if the device name is copied and pasted, it takes only a few seconds to complete the search.

I checked from Chrome's developer tools, and it looks like the search process is executed while typing with the following request.

graph_view.php?action=ajax_search&str=<input string>

I believe this is the cause.

Is there any way to disable the search while typing?

[netniV]

Rather than disable the search when typing, there should be a preset 'delay' before initiating the search so that any further keystrokes do not fire off searches of their own. I think that would be a good enhancement.

[dkuji]

Thanks for the reply.

I think that is a very good idea.
By the way, how should I set the "delay"?
I can't find that parameter in the settings page.

[TheWitness]

It does not look like jsTree has a delay function built into the core of the plugin, bummer. The author shows an example of searching but outside the default plugin.

[TheWitness]

Been a long time since I've looked at this. I'm going to increase the keyup delay to 500ms.

[TheWitness]

How much do you control the permissions at the Cacti level? That sounds like a slow database or a busy one.

[TheWitness]

You might want to consider using the Browser Debug window and then the Network Window to see if the ajax part of the search is slow, or the javascript part is.

[TheWitness]

In the example below. You can see that the search comes back in less than 100ms.

[dkuji]

@TheWitness

Debug window confirmed.
When a search was performed during input, the request for action=get_node was executed about 800 times, with some taking about 60 seconds to respond.

graph_view.php?action=get_node&tree_id=0&id=tree_anchor-xxxx

action=ajax_search took about the same time.

In the case of copy and paste input, the request for action=get_node is executed only once and comes back in 114ms.
action=ajax_search took about the same time.

[dkuji]

I believe I can effectively disable the setting by setting the key-up delay time to a very large value on my Cacti server.
(e.g. 1 hour (3600000 ms))

Is there any problem in this case?

[TheWitness]

Yea, that would effectively disable it. The real question on such a small system is why all the delay? Are you using boost? What is the total size of your rra directory? du -hs rra?

[TheWitness]

I define a large cacti server above 10k hosts and maybe 200k graphs.

[TheWitness]

There are many cacti servers that large and many x times larger where x is confidential.

[dkuji]

@TheWitness
rra directory size was 3.1G.

[TheWitness]

Boost?

[dkuji]

No, Boost is disabled.

[TheWitness]

Enable it.

[dkuji]

Thanks. I am new to the boost feature.
I read the documentation.
I understood that boost is a feature to improve IO performance by caching writes to RRD files.

This feature is not available on my Cacti server.

I can't use this feature on my Cacti server because the server has a script that parses the RRD file every 5 minutes.
If Boost is enabled, the RRD files are updated too slowly and the latest data cannot be parsed.

[TheWitness]

What does that script parse? Is your RRA directory flash? Are you familiar with Data Source Statistics?

[dkuji]

It is analyzed using rrdtool.
The RRA directory is HDD.
This process is difficult to discontinue for a variety of reasons.

[TheWitness]

What data are you grabbing from the RRDfiles?

[dkuji]

Sorry, I cannot answer your question about the analysis of the rrd file as it is out of my scope.

I have changed the keyup delay to 3,600,000.
As expected, the search is no longer executed while typing. However, I am having trouble with the search not executing when I press enter after typing.

[netniV]

The search won't run because you hit enter. It's an automatic filter that appears based on KeyUp. You would have to customise the code more if you expect that kind of behaviour but that's not something we are preparing to do right now I'm afraid.

[TheWitness]

Really, the you should be looking to why the database takes so long to respond. With over 1M graphs and 2.6M data sources, I have a little delay, but not like what you have. I suspect that:

1. You system is un-derpowered
2. You need to be on SSD/NVMe if you can not intelligently work with the system owner to fix their issue with over-querying RRDfiles.

It's likely what they are looking can be found in the DSStat's tables. But we can never know that without knowing what they are doing besides wrecking you system.