Performance comparisons between NetBox 3.7 and 4.4

[markkuleinio]

Using simple pynetbox calls, without threading, for raw comparison:

NetBox 3.7.3 (on PostgreSQL 13.20 on Amazon RDS):

NetBox API 3.7, pynetbox 7.5.0
nb.dcim.devices.all():
Run 1: 3.24 seconds, for 1856 objects
Run 2: 3.31 seconds, for 1856 objects
Run 3: 3.46 seconds, for 1856 objects
nb.dcim.devices.filter(exclude="config_context"):
Run 1: 4.16 seconds, for 1856 objects
Run 2: 3.68 seconds, for 1856 objects
Run 3: 3.49 seconds, for 1856 objects
nb.ipam.prefixes.all():
Run 1: 23.77 seconds, for 15467 objects
Run 2: 23.54 seconds, for 15467 objects
Run 3: 24.19 seconds, for 15467 objects

NetBox 4.4.4 (on PostgreSQL 17.6 on Amazon RDS):

NetBox API 4.4, pynetbox 7.5.0
nb.dcim.devices.all():
Run 1: 3.93 seconds, for 1856 objects
Run 2: 3.37 seconds, for 1856 objects
Run 3: 3.74 seconds, for 1856 objects
nb.dcim.devices.filter(exclude="config_context"):
Run 1: 3.52 seconds, for 1856 objects
Run 2: 3.59 seconds, for 1856 objects
Run 3: 3.44 seconds, for 1856 objects
nb.ipam.prefixes.all():
Run 1: 52.53 seconds, for 15464 objects
Run 2: 52.43 seconds, for 15464 objects
Run 3: 51.72 seconds, for 15464 objects

Using threading=True in pynetbox brings about 15% improvement on the prefixes.all() calls for both 3.7 and 4.4, no difference in the devices.* calls.

Edit: added psql versions above.

[rizlas]

I have the feeling that netbox It's gotten slower. I upgraded from 4.x to the latest version, and scripts have gotten noticeably slower to run.

[chris240189]

my ansible playbooks seem to take longer as well. I don't know if it is netbox itself or ansible. I updated both.

[a4212crew]

same here, running on v4.4.5. API response took 6s to load 6 devices compare to v3.9 which took less than 500ms

[jcollie]

I really don't get what the problem is here… NetBox 3.x is a far less capable system than NetBox 4.x. So many more models, more complex interrelationships, the customizability is insane. Of course 4.x is slower than 3.x running on the same hardware. Sure there probably are some tricks that the developers can do to make things faster, but NetBox 4.x is fundamentally doing more work so it's obviously going to take more time.

[rizlas]

Maybe is better to convert this in a issue?

[jeremystretch]

While I appreciate the observations, the first step in reporting any performance issues is to devise a controlled, reproducible test controlling for all potential variables. This involves:

1. Designating specific software versions up the entire stack
2. Devising a benchmarking strategy
3. Excluding potential complicating factors (such as the pynetbox API client)
4. Populating test data
5. Executing the exact same tests with the same parameters across different versions of the software
6. Performing multiple runs of each test and record the results

Then you have some reliable test data, and not just anecdotes. But please also understand that data alone does not justify a bug report. As @jcollie points out, the introduction of new functionality over time is not free, and certain features do introduce a performance penalty.

I remember a thread some years back where someone boasted that they made "NetBox" so much faster by ripping out all the stuff between the REST API and the database, and just wrote JSON to PostgreSQL database directly. Yep, that will definitely be faster, assuming you don't need things like data validation, security controls, change logging, or any form of business logic. But of course we do need those things, so we tolerate the overhead.

I won't claim that NetBox is as fast as it can be. In fact, I'm nearly certain its performance can be significantly improved given sufficient developer time and focus. Unfortunately, there's little demand for that relative to the demand for new and improved functionality. If you suspect that NetBox has become slower over time, I encourage you to dig and see if you can determine why. It might be something in the application, but it might also be something in your specific deployment; there are many variables. NetBox is open source, so everyone has the ability to trace flows through the application and uncover potential bottlenecks.

If you're able to identify a specific piece of the application that you believe is unduly slow, we'll happy entertain a bug report to explore it further. However, please understand that blanket reports that the application "slower than before" are not actionable.

[tyler-8]

Just based purely on the endpoint in question, v4.2 introduced:

Prefixes can now be scoped by region, site group, site, or location

Which is a generic relation that I would expect would bring some measure of slowness as multiple data type relationships have to be introspected.

To help narrow it down, you can use the fields parameter in the REST API to show retrieve all fields, then start removing one field at a time, until you identify the field that changes the prefixes endpoint performance.