共用方式為


Using PowerShell to Measure Page Download Time

I was recently working with a customer that reported some performance issues in their SharePoint 2013 proof of concept environment, specifically page render time was very poor. I wanted to establish exactly how bad this was and also put in place some basic automated tests to measure response times over a short period of time. I put together a very quick script that measures how long a specific page takes to download and then repeats the test x number of times, as this only measures page download time it doesn't include any client side rendering therefore it isn't wholly accurate, but is a good starting point for assessing performance.

Below is the script itself, it takes two parameters: -URL, which is the URL of the page to download and -Times, which is the number of times to perform the test. By default the script uses the credentials of the current logged on user to connect to the URL provided.

param($URL, $Times)
$i = 0
While ($i -lt $Times)
{$Request = New-Object System.Net.WebClient
$Request.UseDefaultCredentials = $true
$Start = Get-Date
$PageRequest = $Request.DownloadString($URL)
$TimeTaken = ((Get-Date) - $Start).TotalMilliseconds
$Request.Dispose()
Write-Host Request $i took $TimeTaken ms -ForegroundColor Green
$i ++}

To run the script, copy the commands above into a text editor, save as a .ps1 file and run from a suitable machine. An example of the script in action can be found below.

Brendan Griffin

Comments

  • Anonymous
    January 01, 2003
    I can see a geat use for this.  Thanks for positng.

  • Anonymous
    January 01, 2003
    Thanks Paul

  • Anonymous
    May 12, 2014
    Thanks for post.
    Is there a reason/benefit you used 'Net.WebClient' over 'Invoke-WebRequest'?

  • Anonymous
    October 06, 2014
    How do we tag this script to every page in SharePoint , so that it logs page response times of every user into a database or a file ?

  • Anonymous
    October 08, 2014
    @Sri - this is a PowerShell script that runs client side, you would probably want to look at using a different approach to measure performance at that level. It may be better to use IIS logs or the usage database to record/analyse performance.

  • Anonymous
    October 19, 2014
    Is that a correct statement if I say this script will give us Sever Response Time for mentioned site minus "network latency" and minus "end user browser rendering time" ???

  • Anonymous
    October 22, 2014
    @Umar - If you want accurate server processing time you really need to parse the IIS log files rather than using this script.

  • Anonymous
    December 18, 2014
    I prefer to use the following cmd
    Measure-Command {Invoke-WebRequest http://www.nytimes.com}

  • Anonymous
    December 23, 2014
    @Joe Web - That's definitely the way to go now, this script was written to work with PS 2.0 which didn't include that cmdlet.

  • Anonymous
    April 15, 2015
    Thank you for this script, it's exactly what I needed.

  • Anonymous
    April 23, 2015
    You should probably use the .NET Stopwatch class instead. DateTime is not good for this level of measurement

  • Anonymous
    November 06, 2015
    Excellent, just what I have been looking for, thanks Brendan

  • Anonymous
    March 06, 2016
    Little tweak:

    Function Measure-PageLoad {
    param(
    [Parameter(Mandatory=$false, ValueFromPipeline = $true)][string]$URL,
    $Times
    )
    If (!$Times) {$Times = 3}
    If ($URL.IndexOf("://") -lt 0) {
    Write-Debug "URL Input: $URL"
    $URL = "http://$URL"
    Write-Debug "URL Output: $URL"
    }

    $i = 0
    Do {
    $Request = New-Object System.Net.WebClient
    $Request.UseDefaultCredentials = $true
    $TimeTaken = Measure-Command {$Null = $Request.DownloadString($URL)}
    $Request.Dispose()
    Write-Host "Request $i for '$URL' took $($TimeTaken.Milliseconds) ms "
    $TotalTimeTaken += $TimeTaken
    $i ++
    } While ($i -lt $Times)

    Write-Host "Total Time Taken / average: $($TotalTimeTaken.Milliseconds) / $($TotalTimeTaken.Milliseconds/$i) ms`n"
    }

    • Anonymous
      May 28, 2016
      Thanks!