Azure CLI 2.0 slow startup/warmup, command overhead
See original GitHub issueDescription
It takes seconds for any command to complete, the first time you run Azure CLI it’s really really slow to get going. It’s especially annoying that even the built-in help takes more than a couple of seconds to display.
Environment summary
Install Method: How did you install the CLI? (e.g. pip, interactive script, apt-get, Docker, MSI, nightly)
MSI
CLI Version: What version of the CLI and modules are installed? (Use az --version
)
azure-cli (2.0.16)
acr (2.0.11) acs (2.0.14) appservice (0.1.15) batch (3.1.2) billing (0.1.4) cdn (0.0.7) cloud (2.0.7) cognitiveservices (0.1.7) command-modules-nspkg (2.0.1) component (2.0.7) configure (2.0.10) consumption (0.1.4) container (0.1.9) core (2.0.15) cosmosdb (0.1.12) dla (0.0.11) dls (0.0.13) eventgrid (0.1.3) feedback (2.0.6) find (0.2.6) interactive (0.3.9) iot (0.1.11) keyvault (2.0.9) lab (0.0.10) monitor (0.0.9) network (2.0.13) nspkg (3.0.1) profile (2.0.11) rdbms (0.0.6) redis (0.2.8) resource (2.0.13) role (2.0.11) servicefabric (0.0.3) sf (1.0.8) sql (2.0.10) storage (2.0.14) vm (2.0.13)
Python (Windows) 3.6.1 (v3.6.1:69c0db5, Mar 21 2017, 17:54:52) [MSC v.1900 32 bit (Intel)]
Python location ‘C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\python.exe’
OS Version: What OS and version are you using?
Windows 10 Pro 64-bit
Shell Type: What shell are you using? (e.g. bash, cmd.exe, Bash on Windows)
cmd.exe
Issue Analytics
- State:
- Created 6 years ago
- Comments:16 (6 by maintainers)
Top GitHub Comments
Okay, so I went back and checked two more things.
If you run
and say yes, you get to answer a few questions, I chose to disable logging and telemetry.
That’s another 2x perf
Is there any reason logging and telemetry cannot be async?
edit: I updated the spreadsheet with the additional timing information.
Thank you for the measurement. I notice that the telemetry seems to take a toll on the performance for Windows platform (as far as I can tell we didn’t observe the delay on Linux/Unix). I think spawning a new process is blocking the command from exiting and cause the performance issue here. I will do more testing on the Windows platform.
I’m glad that the 250ms response time works for you. However, in many cases, the command communicates with the Azure service. Whenever there is network communication the network latency will dwarf any other factor.
I do agree with you that we can and should do much better when the command is run locally. And thank you for bringing our attention to this.
I filed following two issues to track the specific topics: