Project

General

Profile

Actions

Bug #5645

closed

The interface never responds when search result has a lot of nodes

Added by Benoît PECCATTE over 9 years ago. Updated almost 7 years ago.

Status:
Rejected
Priority:
N/A
Assignee:
-
Category:
Web - Nodes & inventories
Target version:
-
Severity:
Major - prevents use of part of Rudder | no simple workaround
UX impact:
User visibility:
Operational - other Techniques | Technique editor | Rudder settings
Effort required:
Large
Priority:
0
Name check:
Fix check:
Regression:

Description

Why not limit the search time and indicate in the interface that the result has been truncated.

Actions #1

Updated by François ARMAND over 9 years ago

The general need is ok, and it is undeniable.

From an implementation point of view, it's harder than what it seems because we don't know how many requests we have to do to complete a search, and if we don't complete all the request, we most of the time don't have any results.

Example: hostname some_regex AND fs_name some_fs_regex AND apache isinstalled

That search leads to 3 requests. If we barelly complete hostname search on time and fs_name expire, we can't return anything. That's bad.

The very good solution is to change the search engine to NOT work with LDAP. LDAP is bad for composed requests.

The possible solution for now is to actually limit the time, and accept that timeout may lead to no answer at all.

Actions #2

Updated by Benoît PECCATTE over 9 years ago

Is it possible to limit the number of returned results ?
If yes, this should limit the time taken too.
And add a warning if the limit has been reached.

Actions #3

Updated by François ARMAND over 9 years ago

It is possible, and actually what was done, but the results seem even more random - and so, the limit was removed.

Ex: I want to find "node matching that hostname having that soft" => can lead to different results each time, depending on what nodes were taken, and what soft were (because these things are not sorted in LDAP).

So that can have dramatic consequences with dynamic groups.

Actions #4

Updated by François ARMAND almost 7 years ago

  • Severity set to Major - prevents use of part of Rudder | no simple workaround
  • User visibility set to Operational - other Techniques | Technique editor | Rudder settings
  • Effort required set to Large
  • Priority set to 0

We switched to a new ldap backend in Rudder 4.1, which should most improve the performance. We have load test with >5000 nodes that are ok (answer to complexe queries in <10s) - but the diversity in inventories is not great, so they may be misleading.

Actions #5

Updated by François ARMAND almost 7 years ago

  • Status changed from New to Rejected

I'm even closing that one, because we have quite complexe request on our load test (regex, multiple args, etc). So we need more precise case where it fails to be able to correct it.

Actions

Also available in: Atom PDF