Optimize Maintenance interface

[ingeborgoh]

NAV 5.1.1 with large database (3000+ devices)

Whenever you have to edit a Maintenance task it takes "forever" (up to ten seconds) before the Editing window opens up. Every add/removal of components takes another 8-10 seconds. And another wait while the task is saved.

Sometimes the search window under Select components does not work at all or only gives result from the X first netboxes. The windows with scrollbars are way to small to be able to scroll and choose your components.

Can this please be optimized?

[hmpf]

Grapevine says this code hasn't been touched for 15 years :)

Ideas:

• Add paging w/ajax, do not load all devices on every load
• Add search for an even shorter list of devices

[lunkwill42]

@ingeborgoh It may be that this occurs because of some very inefficient SQL generated by the Django ORM, as used by the QuickSelect widget rendered to let the user select components to add to the maintenance task. It generates an extra query for the NetboxEntity table for each netbox in your database, which means 3000+ extra queries in your case.

This might have been efficient before some db model changes that happened years ago ...

Could you please test if the attached patch has any effect at all?

quickselect.patch.txt

[lunkwill42]

A complete and more proper solution for the issues described would be to replace the QuickSelect component with a more dynamic widget that employs the NAV API for component search.

2253 proposes a partial solve for the current backend deficiencies, but the Javascript code used to filter 3000+ device names provided in the HTML document is probably still going to be slow until a reimplementation can be done.

[ingeborgoh]

Yes, the patch makes things 10 times faster (<1 sec in stead of 10 sec)! I can now ask people to use this feature again.

A rewrite of the search interface is still welcome.