Cli: Every sfdx command takes a while

[mhumpolec]

Summary

I would say every sfdx command takes about 20 sec before it starts doing anything

Steps To Reproduce:

1. sfdx force:org:open -u upfsc

Expected result

immediate reaction and browser open

Actual result

cli starting run +0ms
cli checking autoupdater +562ms
rwlockfile read C:\Users\mhumpolec002\AppData\Local\sfdx\update.lock +0ms
cli-engine:hooks init C:\Users\mhumpolec002\AppData\Local\sfdx\client\dist\hooks\plugins\migrate.js +0ms
sfdx:hook:init:plugins:migrate enter +0ms
sfdx:plugins:migrate no v5 plugins need migration +0ms
sfdx:hook:init:plugins:migrate exit +4ms
cli dispatcher +1s
cli-engine:hooks plugins:parse C:\Users\mhumpolec002\AppData\Local\sfdx\client\dist\hooks\plugins\convertFromV5.js +33s
sfdx:hook:plugins:parse:legacy enter +0ms
sfdx:hook:plugins:parse:legacy exit +2ms
cli-engine:hooks plugins:parse C:\Users\mhumpolec002\AppData\Local\sfdx\client\dist\hooks\plugins\convertFromV5.js +74ms
sfdx:hook:plugins:parse:legacy enter +58ms
sfdx:hook:plugins:parse:legacy exit +1ms
cli-engine:hooks prerun C:\Users\mhumpolec002\AppData\Local\sfdx\client\dist\hooks\logAnalytics.js +24ms
sfdx:hook:analytics enter +0ms
sfdx:analytics setting up exit handler +0ms
sfdx:hook:analytics exit +2ms
cli running flow command { _version: '9.0.7' } +32s

Additional information

Windows 10 machine with ton of corporate security on top of it

SFDX CLI Version:
sfdx-cli/6.50.0-9817aece8a (windows-x64) node-v8.9.4

OS and version:
Windows 10 Enterprise, 64bit

[clairebianchi]

@mhumpolec Is this a new issue or has this always been slow?
We are aware of the performance on windows when you are running behind a firewall but knowing if this is a new issue or the same performance as always will help us determine if this is something we just did or Windows did or if this is part of the larger Window performance issue.

[mhumpolec]

It was always like this

Martin

Sent from my mobile with his clever typos correcting, apologies for any nonsense

1. 
   
   1. 2019 v 19:38, clairebianchi [e-mail]:
   
   

@mhumpolec Is this a new issue or has this always been slow?
We are aware of the performance on windows when you are running behind a firewall but knowing if this is a new issue or the same performance as always will help us determine if this is something we just did or Windows did or if this is part of the larger Window performance issue.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[clairebianchi]

Thank you

[gdoenlen]

Adding to this every cli command is beyond slow for me on windows AND linux (ubuntu budgie 18.04). Just printing my orgs (which all sit in files locally) takes 20 seconds.

In regards to the firewall issues why is the CLI reaching out to the internet for things that should be local commands?

Measure-Command {sfdx force:org:list --all -
-verbose}


Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 20
Milliseconds      : 862
Ticks             : 208626283
TotalDays         : 0.000241465605324074
TotalHours        : 0.00579517452777778
TotalMinutes      : 0.347710471666667
TotalSeconds      : 20.8626283
TotalMilliseconds : 20862.6283

[jeffvarnam]

+1. My team has always had this issue with SFDX. We use macs, so it's not limited to Windows users.

I believe the time to execute any DX command is impacted by the number of orgs listed in ~/.sfdx.
I've authed with 55 non-dx orgs and usually have between 2-5 scratch orgs active at any given time. It takes 2 minutes to execute sfdx force:org:list.

[mhumpolec]

we kind of tracked it down to local security, still work on it, but disabling part of our huge security stack improved it. Will see, keep you posted.

[dalefrancum]

I've definitely seen improvement times that I've cleaned out ~/.sfdx, but that is usually short-lived. Just getting a list of orgs has gotten to be so slow that I've created a simple script to parse that folder and give me a list.

[shetzel]

force:org:list does not simply read the cached auth files. The auth and org data can become stale quickly so that command queries every org in ~/.sfdx to ensure the reported information is accurate. The more orgs you have in the directory, the longer force:org:list will take. The number of auth files in ~/.sfdx does not affect any other commands.

We understand that sometimes the cached auth data is good enough. To address that there will be a new command (e.g., force:auth:list) coming soon that will return the cached auth data.

[mhumpolec]

found out the our security stack is responsible for the majority of the slow down, cutting some holes in it we reduced the time from 30s to 5s.

[Erisiel]

found out the our security stack is responsible for the majority of the slow down, cutting some holes in it we reduced the time from 30s to 5s.

@mhumpolec We are currently experiencing similar delays while in the past commands ran faster. Seeing your resolution made me realise we have recently had a change in infrastructure. Do you have any pointers of where to look?

[clairebianchi]

Now that the CLI has been upgraded to OCLIF (V7 of SFDX) you should see performance gains especially on commands that are run only on the client. Please let me know if you are still experiencing increased times on Windows. I am going to close this issue, but we are still working on performance on an ongoing basis.