Server Man
Well-Known Member
- May 17, 2015
- Windows 10
- Chrome 77.0.3865.120
Beginning in PowerShell 7 Preview 3, PowerShell will be sending some additional data points to Microsoft.
This data will allow us to better understand usage of PowerShell and enable us to prioritize our future investments.
These additional points of data were reviewed with the PowerShell community and approved by the PowerShell Committee through the PowerShell RFC process.
What we added
We will continue to use Application Insights to collect the following new telemetry points:
- Count of PowerShell starts by type (API vs console)
- Count of unique PowerShell usage
- Count of the following execution types:
- Application (native commands)
- ExternalScript
- Script
- Function
- Cmdlet
- Enabled Microsoft experimental features or experimental features shipped with PowerShell
- Count of hosted sessions
- Microsoft owned modules loaded (based on white list)
This data will include the OS name, OS version, the PowerShell version, and the distribution channel when provided.
We will continue to share portions of our aggregated data with the PowerShell community through the
Public PowerBi report.
Why we added it
We want to make PowerShell better and believe this can be achieved by better understanding how PowerShell is being used.
Through these additional data points we will get answers backed by data to the following questions:
To ensure we are getting an accurate picture of how everyone uses PowerShell, not just those most
vocal/involved in the community, we made improvements in our telemetry.
PowerShell usage telemetry will allow us to better prioritize testing, support, and investments.
Performance testing
When implementing this telemetry we took special care to ensure that there would not be a discernible performance impact.
The telemetry is collected through Application Insights and is batched and sent on a separate thread in order to reduce impact.
We also conducted tests to verify that there would not be a noticeable difference in PowerShell performance.
In order to test the performance impact of the telemetry we ran our test suite 5 times with and 5 times without the telemetry changes
and compared the average time for test completion.
The tests had a 1% difference in average completion time with the telemetry-enabled test runs actually having the faster average completion. The difference in average completion time, however, was not statistically significant.
We also tested the impact of collecting telemetry on startup time for both cold starts (first start-up of PowerShell) and warm starts (all future starts). We found that on average cold starups were .028 seconds slower with the additional telemetry while warm startups were, on average, .027 slower. The average performance impact was around 4% and all start-ups during the test runs performed faster than .6023 seconds.
How to disable
The telemetry reporting can be disabled by setting the environment variable POWERSHELL_TELEMETRY_OPTOUT to true, yes, or 1.
This should not be done in your profile, as PowerShell reads this value from your system before executing your profile.
Feedback and issues
If you encounter any issues with PowerShell telemetry, the best place to get support is through our GitHub page.
The post New Telemetry in PowerShell 7 Preview 3 appeared first on PowerShell.
Continue reading...
This data will allow us to better understand usage of PowerShell and enable us to prioritize our future investments.
These additional points of data were reviewed with the PowerShell community and approved by the PowerShell Committee through the PowerShell RFC process.
What we added
We will continue to use Application Insights to collect the following new telemetry points:
- Count of PowerShell starts by type (API vs console)
- Count of unique PowerShell usage
- Count of the following execution types:
- Application (native commands)
- ExternalScript
- Script
- Function
- Cmdlet
- Enabled Microsoft experimental features or experimental features shipped with PowerShell
- Count of hosted sessions
- Microsoft owned modules loaded (based on white list)
This data will include the OS name, OS version, the PowerShell version, and the distribution channel when provided.
We will continue to share portions of our aggregated data with the PowerShell community through the
Public PowerBi report.
Why we added it
We want to make PowerShell better and believe this can be achieved by better understanding how PowerShell is being used.
Through these additional data points we will get answers backed by data to the following questions:
- Is the PowerShell Core user-base growing?
- How is PowerShell being used? What is the usage distribution across command types and session type?
- How can we encourage PowerShell Core usage growth?
- What are issues that customers are hitting in PowerShell Core?
- What versions of PowerShell tools and services should Microsoft continue to support?
- Which experimental features are being used and tested? Which experimental features should we invest in?
- How can we optimize the engine size and efficiency of PowerShell for cloud scenarios?
To ensure we are getting an accurate picture of how everyone uses PowerShell, not just those most
vocal/involved in the community, we made improvements in our telemetry.
PowerShell usage telemetry will allow us to better prioritize testing, support, and investments.
Performance testing
When implementing this telemetry we took special care to ensure that there would not be a discernible performance impact.
The telemetry is collected through Application Insights and is batched and sent on a separate thread in order to reduce impact.
We also conducted tests to verify that there would not be a noticeable difference in PowerShell performance.
In order to test the performance impact of the telemetry we ran our test suite 5 times with and 5 times without the telemetry changes
and compared the average time for test completion.
The tests had a 1% difference in average completion time with the telemetry-enabled test runs actually having the faster average completion. The difference in average completion time, however, was not statistically significant.
We also tested the impact of collecting telemetry on startup time for both cold starts (first start-up of PowerShell) and warm starts (all future starts). We found that on average cold starups were .028 seconds slower with the additional telemetry while warm startups were, on average, .027 slower. The average performance impact was around 4% and all start-ups during the test runs performed faster than .6023 seconds.
How to disable
The telemetry reporting can be disabled by setting the environment variable POWERSHELL_TELEMETRY_OPTOUT to true, yes, or 1.
This should not be done in your profile, as PowerShell reads this value from your system before executing your profile.
Feedback and issues
If you encounter any issues with PowerShell telemetry, the best place to get support is through our GitHub page.
The post New Telemetry in PowerShell 7 Preview 3 appeared first on PowerShell.
Continue reading...