[OpenNMS/opennms] 3e0cb6: perf(collectd): build metadata scopes lazily durin...

  Branch: refs/heads/ronny/reduce-collectd-dbload
  Home:   https://github.com/OpenNMS/opennms
  Commit: 3e0cb63516587a8d1803cc6ddf930cf7260ea93a
      https://github.com/OpenNMS/opennms/commit/3e0cb63516587a8d1803cc6ddf930cf7260ea93a
  Author: Ronny Trommer <[email protected]>
  Date:   2026-08-28 (Fri, 28 Aug 2026)

  Changed paths:
    M features/collection/client-rpc/src/main/java/org/opennms/netmgt/collection/client/rpc/CollectorRequestBuilderImpl.java
    M features/collection/core/src/main/java/org/opennms/netmgt/collection/core/CollectionSpecification.java

  Log Message:
  -----------
  perf(collectd): build metadata scopes lazily during collection

Collectd builds the Mate entity scopes eagerly twice per interface per
collection cycle, whether or not any service parameter contains a
metadata expression:

  - CollectionSpecification.getServiceParameters() resolves its
    ScopeProvider before handing the scope to the Interpolator.
  - CollectorRequestBuilderImpl.execute() constructs a FallbackScope
    over the node and interface scopes up front.

Each scope build opens a read-only transaction and issues several
selects. getScopeForNode() loads the node, forces the lazily mapped
node_metadata element collection and pulls the asset record;
getScopeForInterface() loads the ipinterface row and forces
ipinterface_metadata. That is roughly ten selects and four
transactions per interface per cycle that a deployment pays even
with no metadata expressions configured anywhere.

Wrap both in LazyScope, which defers construction to the first lookup
and memoizes the result. The Interpolator only consults a scope when
the input actually contains an expression, so the cost becomes
demand-driven. In CollectorRequestBuilderImpl the two scopes are
wrapped individually, so an expression resolved from node metadata
never triggers the interface lookup: FallbackScope stops at the first
match.

This applies the same treatment the thresholding path already
received in NMS-20007 and NMS-16966.

No functional change: the resolved values and their precedence are
unchanged, only the point in time at which the lookups happen.

Assisted-by: ClaudeCode:claude-opus-5
Signed-off-by: Ronny Trommer <[email protected]>



To unsubscribe from these emails, change your notification settings at https://github.com/OpenNMS/opennms/settings/notifications


_______________________________________________
Please read the OpenNMS Mailing List FAQ:
http://www.opennms.org/wiki/index.php?page=MailingListFaq
opennms-cvs mailing list

To *unsubscribe* or change your subscription options, see the bottom of this page:
https://lists.sourceforge.net/lists/listinfo/opennms-cvs