Other

SharePoint latency – How to keep it in check

SharePoint intra-farm latency is one of SharePoint hardware minimum requirements, but it often goes unnoticed and unchecked. Check out how to measure it!

Intra-farm latency is latency measured between web front end servers and database servers in a SharePoint environment. Consistently low intra-farm latency is one of the SharePoint hardware requirements for a stretched farm. 

Initially, when SharePoint 2013 was released, stretched farms were unsupported, but after continuous efforts to review and update the product performance and capacity boundaries, stretched farms for SharePoint 2013 became supported as of April 2013.

For a stretched farm architecture to work as a supported high-availability solution, the following prerequisites must be met: There must be a highly consistent intra-farm latency of less than one millisecond, 99.9% of the time, over a period of ten minutes. Intra-farm latency is commonly defined as the latency between the front end web servers and the database servers. The bandwidth speed must be at least one gigabit per second.

You can read Microsoft’s official statement on hardware and software requirements for SharePoint 2013 here

Those requirements are still valid, and Microsoft recommends that intra-farm latency should be this low and monitored even for farms that are hosted on the same data center. Microsoft Premier Field Engineers (PFE) often check intra-farm latency during troubleshooting, as some communication issues may arise that would be hard to trace back to intra-farm latency. When SharePoint is not running and performing at the optimum level, there is a big list of possible culprits that SharePoint administrators check before they check the intra-farm latency. In addition, SharePoint administrators often do not have privileges to change the network, firewall, or other parts of the farm that may cause high intra-farm latency.

How to measure SharePoint latency?

There are a few different approaches to collecting this metric. The first, and simplest, is to connect to the SharePoint web front end server and manually ping the database servers. Let the ping run for 10 minutes, collect all the results, and check to see that the server is compliant. After checking the connection between the SharePoint web front end server and that particular database server, we also need to check all the other combinations of front end and database servers. A bit of a pain. 🙁

The other approach is to leverage PowerShell scripting and get the results automatically. Using the provided PowerShell script, we can determine if the SharePoint farm is compliant. The PowerShell script should be used on the web front end server to get the most accurate results. It will also provide additional latency metrics collected during the interval.

Check out the script here:

param([String[]] $SPServerNames)

$ping = New-Object System.Net.NetworkInformation.ping

for ($i = 0; $i -le $SPServernames.Length - 1; $i++) {
 $status = $ping.send($SPServernames[$i]).Status
 
 if ($status -ne "Success") {
 throw ("Testing connectivity to server $($SPServerNames[$i]) failed")
 }
}

$ScriptBlock = {
 param($InHost) 
 $start = [DateTime]::Now
 $ping = New-Object System.Net.NetworkInformation.ping

 

 $sentPings = 0
 $receivedPings = 0
 $badPings = 0
 
 while ([datetime]::now -le $start.AddMinutes(10)) { 
 $outping = $ping.send($InHost)
 $sentPings++

 if ($outping.Status -eq "Success") {
 $receivedPings++
 if ($outping.RoundtripTime -ge 1) {
 $badPings++
 }
 }

 Start-Sleep -Milliseconds 10
 }

 $OutputObject = [PSCustomObject]@{
 SentPings = $sentPings
 ReceivedPings = $receivedPings
 BadPings = $badPings
 }

 return $OutputObject
}

foreach ($i in $SPServernames) {
 Start-Job $ScriptBlock -ArgumentList $i -Name "$i.latency_test" | Out-Null
}

While (Get-Job -State "Running") { Start-Sleep -Seconds 10 }

$output = @{}
foreach ($i in $SPServernames) {
 $output[$i] = Receive-Job -Name "$i.latency_test"
}
Remove-Job *

$isValid = $TRUE;
foreach ($i in $SPServernames) {
 if ($output[$i].BadPings / $output[$i].SentPings -ge 0.001) {
 $isValid = $FALSE;
 Write-Host "The server $($i) has failed latency check. Number of pings exceeding 1ms response time: $($output[$i].BadPings)/$($output[$i].SentPings)" -ForegroundColor Red
 }
}

if ($isValid) {
 Write-Host "The network is compliant with SharePoint requirements"
}

Both of these options are a bit complicated and very time-consuming. The easiest way to keep your latency in check is to use a tool like Syskit Insights, a SharePoint performance monitoring tool, which checks the intra-farm latency by default. Using Syskit Insights intelligent alerting, SharePoint administrators can proactively check network latency and ensure that they catch problems before end users do. You can achieve all this without even connecting to SharePoint servers and encumbering your production servers, as Syskit Insights can be installed outside the SharePoint farm.

Subscribe to our Newsletter

Related Posts