Recursive Power Calculation

[xarmin-dev]

NetBox version

v4.1.6

Feature type

Change to existing functionality

Triage priority

I volunteer to perform this work (if approved)

Proposed functionality

I am proposing an alternative solution to previously proposed recursive power calculations, that does not require database modification or Many-to-Many models, and is hopefully less complex in nature.

I recently delved into the NetBox code after using it at my MSP business for a year or so, so apologies for any incorrect nomenclature in the below.

Here is proposed simplified pseudocode, modifying the get_power_draw function:

def get_power_draw(self, depth_context=0, powerports_context=None):

  if self.allocated_draw is not None: return self_power_utilization
  if depth_context > MAX_POWER_CALCULATION_DEPTH: return 0

  if not powerports_context: powerports_context = []

  total = 0
  powerports = self.get_downstream_powerports()

  for port in powerports:
    if powerport.device.identifier in powerports_context: break
    
    powerports_context.append(powerport.device.identifier)
    total += powerport.get_power_draw(depth_context + 1, powerports_context)['allocated']

  return total

Additionally, I propose modifying the UI to use the maximum_draw specified for the queried device in utilization calculations, rather than that of the Power Feed.

Advantages

• User-configurable max recursion depth to address performance concerns.
• Simple to understand and maintain.
• Infinite loop protections.
• No database changes.
• allocated_draw can continue to be used as an override for downstream power calculations.

Disadvantages

• Increased performance impact.

I am happy to make these changes and submit a pull request. It seems that this is a fairly common request in the community, and it would certainly help my own business as well.

Previous Issues (I am sure I missed some!)

• Power Utilization not fully calculated #17894
• Power Utilization not fully calculated #17843
• Power Ports draw: add automatic calculation based on connected devices on power outlets #5560
• Cable Trace for Power Port/Outlet: show all segments for path to the Power Panel #5559

Use case

Many environments outside of a datacenter are likely to use a PDU, connected to a UPS, connected to a Power Feed. Power is not accurately modeled in these situations, and can be confusing to users.

Allowing at least one deeper level of power calculation would allow NetBox users to more accurately determine and plan power usage across PDU, UPS, and Power Feeds.

Database changes

None

External dependencies

None

[bctiemann]

Seems like a good approach, clear and simple (and would address a lot of piecemeal bugs as noted). Please be sure there are adequate unit tests covering loop conditions, and if we can get some statistics on what kind of performance impact this causes that would also be a good idea.

[xarmin-dev]

Thanks @bctiemann! I'll get started on this, and make sure we get that coverage and those statistics.

[xarmin-dev]

I have some initial results from performance testing. I created:

• 2 x 3-Phase Power Feeds, associated with a Rack
• 2 x UPS-like devices, one connected to each Power Feed
• 2 x PDU-like devices, one connected to each UPS
• 72 x Server-like devices, 36 connected to each PDU

I observed the following, using the development branch of NetBox, the new recursion function set to a max depth of one, and the same set to a max depth of three.

(Load Time | SQL Time | Queries)

From Rack Template

• Development Branch: 2414ms | 85ms | 40 queries
• Recursive, MAX_DEPTH=1: 1142ms | 123ms | 59 queries
• Recursive, MAX_DEPTH=3: 3319ms | 339ms | 205 queries

From UPS Device Template

• Development Branch: 663ms | 57ms | 35 queries
• Recursive, MAX_DEPTH=1: 748ms | 88ms | 35 queries
• Recursive, MAX_DEPTH=3: 2025ms | 192ms | 110 queries

From PDU Device Template

• Development Branch: 1165ms | 65ms | 39 queries
• Recursive, MAX_DEPTH=1: 680ms | 62ms | 39 queries
• Recursive, MAX_DEPTH=3: 1838ms | 169ms | 106 queries

These times vary 200-300ms each page load. I am doubtful there is a way to make any significant optimizations without adding significant complexity.

I can continue working on this, but would be curious to hear thoughts as to whether this is an acceptable performance impact for the functionality.