Simple choco commands have become very slow (including help commands)

[mlalkaka]

What You Are Seeing?

Hello, simple choco commands have started taking very long to run. Below, I've pasted the output of running choco list -? with the Measure-Command cmdlet to measure how long the Chocolatey command took to run. I'm running Chocolatey v0.10.8, but the problem was occurring on a previous version as well. Is this a known issue?

What is Expected?

Here is the measured result on a machine that doesn't exhibit this problem.

PS C:\windows\system32> Measure-Command { choco list -? --debug --verbose }

Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 0
Milliseconds      : 544
Ticks             : 5443450
TotalDays         : 6.30028935185185E-06
TotalHours        : 0.000151206944444444
TotalMinutes      : 0.00907241666666667
TotalSeconds      : 0.544345
TotalMilliseconds : 544.345

How Did You Get This To Happen? (Steps to Reproduce)

Here is the measured result on the machine that does exhibit this problem.

PS C:\windows\system32> Measure-Command { choco list -? --debug --verbose }

Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 3
Milliseconds      : 845
Ticks             : 38456883
TotalDays         : 4.451028125E-05
TotalHours        : 0.00106824675
TotalMinutes      : 0.064094805
TotalSeconds      : 3.8456883
TotalMilliseconds : 3845.6883

Output Log

Here are the logs from the machine exhibiting this issue: https://gist.github.com/mlalkaka/8db0943728f830089e553fc8f8125093.

[ferventcoder]

You might want to add --trace (and use choco list -lo)

[mlalkaka]

Sure, I've included that below. Still, I figure it's informative that this is happening even for choco list -?, because that doesn't do as much as choco list -lo.

What is Expected?

PS C:\windows\system32> Measure-Command { choco list -lo --debug --verbose --trace }

Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 1
Milliseconds      : 962
Ticks             : 19620069
TotalDays         : 2.27084131944444E-05
TotalHours        : 0.000545001916666667
TotalMinutes      : 0.032700115
TotalSeconds      : 1.9620069
TotalMilliseconds : 1962.0069

How Did You Get This To Happen? (Steps to Reproduce)

PS C:\windows\system32> Measure-Command { choco list -lo --debug --verbose --trace }

Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 19
Milliseconds      : 581
Ticks             : 195818694
TotalDays         : 0.000226642006944444
TotalHours        : 0.00543940816666667
TotalMinutes      : 0.32636449
TotalSeconds      : 19.5818694
TotalMilliseconds : 19581.8694

Output Log

https://gist.githubusercontent.com/mlalkaka/8db0943728f830089e553fc8f8125093/raw/0de8287c1cd6eea86b290ae49758c2ad0d3599a9/choco-list.log

[ferventcoder]

It was suggested that IPv6 may be the culprit of some of this. You might check into that.

[ferventcoder]

https://marcesher.com/2018/01/15/windows-ipv6-slow-or-broken-resolved/

[bcurran3]

PREFACE: I do a lot of Chocolatey re-installs in testing new versions of InstChoco - https://chocolatey.org/packages/InstChoco

I've noticed that if I've re-installed Chocolatey, cleanup on the next choco run can add a delay.

When run with administrative privileges I don't see any errors, just an abnormal delay. When run without administrative privileges I see:

C:\>clist -l Chocolatey v0.10.8 Professional This is try 1/3. Retrying after 300 milliseconds. Error converted to warning: Access to the path 'C:\ProgramData\chocolatey\choco.exe.old' is denied. This is try 2/3. Retrying after 400 milliseconds. Error converted to warning: Access to the path 'C:\ProgramData\chocolatey\choco.exe.old' is denied. Maximum tries of 3 reached. Throwing error.

[bcurran3]

OK, that didn't display very well!

Here's this...

[dehidehidehi]

It was suggested that IPv6 may be the culprit of some of this. You might check into that.

Not the first time I've had to disable IPv6 for my networking device to fix general network slowness. This worked for me.

[pauby]

As we have a solution, for this case, and there have been no updates for some time on this issue, I'm going to go ahead and close it. We can always reopen it again if necessary.