Doc: Troubleshooting: Optimise apply rules and group assign conditions

doc/15-troubleshooting.md

@@ -178,6 +178,8 @@ C:\ProgramData\icinga2\var\log\icinga2> Get-Content .\debug.log -tail 10 -wait
 
 ## Icinga starts/restarts/reloads very slowly
 
+### Try swapping out the allocator
+
 Icinga performs a lot of memory allocations, especially during startup.
 Swapping out the allocator may increase the startup performance.
 The following instructions assume you run Linux and systemd.
@@ -230,6 +232,97 @@ icinga2 7764 nagios  mem    REG                8,5   744776 2631636 /usr/lib/x86
 #
 ```
 
+### Optimise apply rules and group assign conditions
+
+#### Remove actually unused apply rules
+
+If `icinga2 daemon -C` warns you like shown below and "it's okay" for you
+as everything behaves as desired, consider removing
+or commenting out the respective apply rule.
+
+```
+[...] warning/ApplyRule: Apply rule '...' (...) for type '...' does not match anywhere!
+```
+
+At least consider changing the `assign where` filter from, say
+`assign where my_complex_filter()`, to `assign where false && my_complex_filter()`.
+`&&` will evaluate `false` first and in an instant.
+If it's not true, `&&` will "return" `false` and skip `my_complex_filter()`.
+
+Same for `assign where` conditions in groups. In this case removing just
+the `assign where` line(s) is enough if you'd like to keep the group itself.
+
+#### Create single objects not via apply rules
+
+If possible, replace constructs like the immediately following with the below one.
+
+```
+apply Service "syspatch" {
+	// ...
+	assign where host.name == "firewall" || host.name == "ssh-jump-box"
+}
+```
+
+```
+object Service "syspatch" {
+	// ...
+	host_name = "firewall"
+}
+
+object Service "syspatch" {
+	// ...
+	host_name = "ssh-jump-box"
+}
+```
+
+This way Icinga won't have to evaluate
+`host.name == "firewall" || host.name == "ssh-jump-box"`
+for all of your hosts.
+
+At least upgrade to Icinga v2.13.6+ which optimizes apply rules as shown above.
+In this case such `assign where` filters even save time compared to e.g.
+`assign where host.vars.os == "OpenBSD"` if such hosts are a minority.
+
+Group membership assign conditions aren't optimized by v2.13.6.
+But they can just be replaced with constructs like this one:
+
+```
+object Host "firewall" {
+	// ...
+	groups = [ "OpenBSD hosts" ]
+}
+```
+
+#### Reduce `assign where` filter complexity
+
+If neither removals, nor O(1) conditions (`assign where false && ...`), nor O(n) conditions
+(`assign where host.name == "firewall" || host.name == "ssh-jump-box"`)
+are an option and a regular filter is needed, keep it as simple as possible.
+
+The less complex an `assign where` filter is,
+the more time Icinga saves while loading its config.
+**I.e. the following is a bad example.**
+
+```
+assign where ( match("MySQL*", host.name) || match("Maria*", host.name)
+	|| match("Postgre*", host.name) || match("Redis*", host.name) || match("Elastic*", host.name) )
+```
+
+Preferably only a single custom var is checked. Ideally just whether it's set.
+(`assign where host.vars.db` or "is true (or set)" operator in Director.)
+Otherwise, prefer `==` over `match()`. (In Director avoid `*` wildcards.)
+
+If you're using the Director, you can create such a custom var automatically and
+pattern-based via a _Sync rule_. Navigate to its _Properties_ and add a new property:
+
+* Destination Field: Custom variable (vars.)
+* Custom variable: e.g. `db`
+* Source Column: Custom expression
+* Source Expression: e.g. `true`
+* Set based on filter: Yes
+* Filter Expression: e.g. `host=MySQL*|host=Maria*|host=Postgre*|host=Redis*|host=Elastic*`
+* Merge Policy: replace
+
 ## Configuration Troubleshooting <a id="troubleshooting-configuration"></a>
 
 ### List Configuration Objects <a id="troubleshooting-list-configuration-objects"></a>