-
Notifications
You must be signed in to change notification settings - Fork 100
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
Get-ChocoInstalledPackage is very slow, causing long Test, Set, and Upgrade times for multiple packages #90
Comments
No reason - was just discussing this with a colleague recently. |
I think refactoring would be a great idea |
As long as it is done in a compatible way that is. |
Is this something you want to add as a 2.x milestone possibly replacing #80, or is this just a nice idea? If no one else is going to be working on it, I'd be glad to try to take a first whack, I've never contributed to a project or worked with AppVeyor before so I'll have a little bit of a learning curve to get over to get used to the tools before I can make any real contribution on the project itself. |
2.x is current, 3.x is next major. |
@jrdnr For contributions, I'd suggest reading Chocolatey's CONTRIBUTING at https://github.com/chocolatey/choco/blob/master/CONTRIBUTING.md#contributing-1. It's very comprehensive and helpful for first time folks to regular contributors alike. |
A couple of things to keep in mind:
|
Ok I'll review the contribution articles |
I finally got a chance to sit down and finish getting my head around how everything ties together, and see that a few of my original assumptions were a little off base. It looks like there are probably a few good reasons (ie exposing a limited set of parameters to cChocoPackageInstallerSet for 1) that there should be both cChocoPackageInstaller vs ..InstallerSet. Also due to the way DSC processes the module the only way to only pull the The only ways I have been able to come up with to improve the speed of the dsc run would be to directly work on @ferventcoder would it make sense to update the title on this issue, or close it and open the issue somewhere else? |
Update the title. |
Is this an issue we can address in the DSC resource by caching to disk or something along those lines, or should the fix for this really be made in the core of |
@jrdnr |
I think we should work on making it better here. |
More explanation - Puppet and Chef run this query one time before all packages during a run and cache the results for all. I'm actually surprised (well not really) that Microsoft decided to ignore this pattern. |
Doing some testing the simplest work around I've found is to add an |
Storing to a file could have security implications, would you be able to hold a lock on the file or store it somewhere secure during the run? |
Unfortunately coming back around to the initial problem with DSC being stateless, I don't think file locking is an option. However because DSC runs as System we can easily write to a secure location. My current version tests for and if needed creates a cChoco directory in In the current implementation I'm using last write time to ensure the cached package list was updated less than 60 seconds ago, if its stale or does not exist I re-run From limited testing it does not appear as though DSC runs a Test-* after running a Set-* and the default LCM config will run another test for 30 min, The only time I see the 60 second limit potentially being a problem would be if someone were to run a |
…mData Get-ChocoInstalledPackage must run and parse choco list -lo for every package managed by DSC This commit ensures a cChoco folder in ProgramData and exports the custom object to Clixml, and will simply read it from file if last write time is less that 60 Seconds ago.
@ferventcoder, sorry I'm new to the open source collaboration (and I know you have a life and a day job). I'm just not sure about next steps. Should I go ahead and submit a pull request now, or do we continue discussing the proposed solution until any potential issues have been addressed and then I submit the PR? |
Go for the PR, we have the basics down and are agreeing on them. Specifics are easily changed. |
…ages_for_faster_run * development: (chocolateyGH-87) Moved to using reduced output (maint) formatting (chocolateyGH-70) Apply Apache v2 Licensing (chocolateyGH-85) Pass the source to cChocoPackageInstallerSet correctly (chocolateyGH-44) Pass the Source to choco correctly Added version to example (chocolateyGH-77) Push to gallery on new tags (maint) formatting (chocolateyGH-72) PowerShell scripts in format for signing # Conflicts: # DSCResources/cChocoPackageInstall/cChocoPackageInstall.psm1
The Get-ChocoInstalledPackage function pulls a new list from 'choco list -lo -r' costing measurable system impact when choco is installing several packages. This commit will allow the Installed package list to be cached locally in the $env:ChocolateyInstall folder for 60 seconds before pulling a new list.
…n' into development * (chocolateyGH-90)_Cache_InstalledPackages_for_faster_run: (chocolateyGH-90) Implemented Caching Package list to File Resource uses its own static file location Fix $path hard coded to C:\ (chocolateyGH-90) Update Get-ChocoInstalledPackage to Cache to ProgramData
…mData Get-ChocoInstalledPackage must run and parse choco list -lo for every package managed by DSC This commit ensures a cChoco folder in ProgramData and exports the custom object to Clixml, and will simply read it from file if last write time is less that 60 Seconds ago.
The Get-ChocoInstalledPackage function pulls a new list from 'choco list -lo -r' costing measurable system impact when choco is installing several packages. This commit will allow the Installed package list to be cached locally in the $env:ChocolateyInstall folder for 60 seconds before pulling a new list. # Conflicts: # DSCResources/cChocoPackageInstall/cChocoPackageInstall.psm1
Previously Get-ChocoInstalledPackage function pulled a new list from 'choco list -lo -r' costing measurable system impact when choco was installing several packages. This allows the installed package list to be cached locally in the $env:ChocolateyInstall\cache folder for 60 seconds before pulling a new list. Also enabled purging the Cache when a package is changed.
…_faster_run (GH-90) Implemented Caching Package list to File
@ferventcoder This issue can be closed now correct? |
Because cChocoPackageInstallerSet, just provides a foreach overlay for cChocoPackageInstaller it is very slow 1-2 seconds per package due to the time it takes to run
choco list -lo
Is there a fundamental reason that cChocoPackageInstaller could not be refactored to allow an array of package names, and then change cChocoPackageInstallerSet to simply be an alias?
This would also address issue #80.
The text was updated successfully, but these errors were encountered: