Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Nut driver enumerator optimize (FTY) #81

Open
wants to merge 33 commits into
base: FTY
Choose a base branch
from

Conversation

jimklimov
Copy link
Member

The 42ity equivalent to networkupstools#682, without the older improvements which are in FTY and are not yet in upstream (part of 682 now).

jimklimov added 21 commits April 1, 2019 02:11
…led to add a normally-named one because it already exists (clean it up and then add)
…sh the non-instance service (for global config)
… setter into smf_setSavedUniq() for other use-cases
…up --get-device-for-service processing where possible
…up --get-device-for-service processing where possible (typo fix)
…r faster --get-service-for-device processing
…ceName data to be consistent (ensuring it is is expensive and belongs elsewhere)
…and upslist_savednames_find_mismatch() to upgrade entries without saved names
…e) and get_device_for_service() into routines
…ssing() into single-run and daemonized modes, to update inconsistent configs
@jimklimov jimklimov added the DNMY label Apr 10, 2019
@jimklimov
Copy link
Member Author

DNMY : As agreed, we'll run a test with a system that has many (hundreds range) driver sections defined to measure if this PR brings benefits, and to estimate where to go next in this area.

Points of interest:

  • compare the time it takes to find which NUT driver to configure for a service unit management
  • compare the time it takes for initial configuration of the service unit wrappings from a given ups.conf
  • compare the time it takes for reboot (for stop and for startup of all drivers) with existing service unit configuration
  • (possible evolution vector) keep an eye on system load and latency of systemd when it is told to manage a burst of hundreds of units in a short timeframe (system startup) - should we bolt on some throttling here, or can it go as is?

@jimklimov
Copy link
Member Author

jimklimov commented May 21, 2019

Note: There are some further improvements staged in a development repo at https://github.com/jimklimov/nut/tree/FTY-upssvc-201904 and not yet PRed because the updated codepaths are not yet integrated with the main codebase to replace earlier implementations. When scheduling allows, I'd proceed on that.

…ot active for simple and daemon modes currently)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant