Performance

Onedrive for Business Design Specification

Having worked on this document for quite some time I felt the need to publish it just about now. I see alot of attention on the Onedrive for business client as it has matured greatly over the past year and many national and international companies are looking towards what this solution can offer. The below design outlines a lot of these considerations, including network latency, legislation, features and of course a large collection of valuable links when considering the implementation of Onedrive for Business.
I will update document as my work brings me further into this area. Until then I hope you will enjoy this piece of work and benefit as much from it as I have.

Onedrive for Business Design Specification (located on Google drive)

SharePoint Online – Performance – Basic Troubleshooting

Classic case: Customer reports in “SharePoint Online performance is slow. [period]”
Account Manager, Product Manager, Project Manager comes running 4 weeks after due date, customer wont accept the solution with the given performance. Ok…. Lets gather the tools for first steps:

Toolbox includes at this point
– PSping utility from PSTools(PSTools )
– Tracert utility from Microsoft (TraceRT )
– Browser Development Tools (F12 for Internet Explorer, Firefox or Chrome)

First step
Compare performance from your location with the client location using the Browser development tools. Are they the same?
If yes, problem usually lies in the configuration of SharePoint Online. Start testing from your location and don’t bother asking customer for client computer, remote login, network information.
If no, problem usually lies from customer client machine and SharePoint Online server. Start testing from customer client machine at their location. Ask them for information regarding their network configuration. Do they have proxy? Are they running old router/switch between?

When you have determined the location of your challenge, proceed to second step.

Second step
Second step of troubleshooting SharePoint Online performance is to measure ping time to the tenant as well as traceroute in order to locate route and geolocation of the tenant.
I use the following to complete that, either run it myself or ask the client to run it from their location.
psping.exe -n 20 tenant.sharepoint.com:443 > PsPingResult.txt
timeout 30 /nobreak
tracert tenant.sharepoint.com > TracertResult.txt
timeout 30 /nobreak

From that I derive the following:
1: For optimal performance, ping time is between 30-50ms stable.
2: Number of Route hops between 12-15.
3: Use https://www.iplocation.net/ to get most likely geolocation of tenant from returned public IP.

Psping.exe is part of SysInternals PSTools package.

Lastly again back to developer tools.
Collect performance report and look for errors in the console. Look for external http requests, certificate validation errors, script errors.

What the numbers show you
A: Ping times of more than 50MS or route hops more than 12-15 would lead me to look at the network with possible causes being:
Linespeed, old or outdated network equipment, tenant geolocation, proxy filtering, non-optimal routing.

B: Usually there are little or no problems in the direct network measurement and it will come down to the browser Development Tools. Note the difference between DOM loaded and Fully rendered. Client really dont care about DOM download, as they are only interested in the fully rendered page. So what can be causes of slow rendered pages:
Certificate errors, script errors, poor client hardware, proxy filtering, Antivirus, Poor coding.

CRM – Performance – AsyncOperationBase Table

Quite a while back had some issues upgrading a CRM instance. It turned out the amount of ASync operations during the lifetime of the CRM application had generated quite a lot of entries. (millions). For some reason I had a hard time find the root cause of this, which turned out to be a lot more general than just relating to an upgrade. I rarely see CRM installations where a clean up job is created, so most CRM installations will actually suffer from large amount of async operations stored.

Have a look at your AsyncOperationBase table and see how many entries are there. You might be surprised.

Below are the SQL lines I ran/set up as a maintenance plan in order to reduce the number. Depending on the number of records, it might be necessary to run the scripts a few times.

Code is from referenced KB article: http://support.microsoft.com/kb/968520/en-us


IF EXISTS (SELECT name from sys.indexes
                  WHERE name = N'CRM_AsyncOperation_CleanupCompleted')
      DROP Index AsyncOperationBase.CRM_AsyncOperation_CleanupCompleted
GO
CREATE NONCLUSTERED INDEX CRM_AsyncOperation_CleanupCompleted
ON [dbo].[AsyncOperationBase] ([StatusCode],[StateCode],[OperationType])
GO

while(1=1)
begin
 declare @DeleteRowCount int = 10000
 declare @rowsAffected int
 declare @DeletedAsyncRowsTable table (AsyncOperationId uniqueidentifier not null primary key)
 insert into @DeletedAsyncRowsTable(AsyncOperationId)
 Select top (@DeleteRowCount) AsyncOperationId from AsyncOperationBase
 where 
  OperationType in (1, 9, 12, 25, 27, 10) 
  AND StateCode = 3 
  AND StatusCode in (30, 32)
  /*AND CompletedOn <= DATEADD(mm, -1, GETDATE())*/
 
 select @rowsAffected = @@rowcount 
 delete poa from PrincipalObjectAccess poa 
   join WorkflowLogBase wlb on
    poa.ObjectId = wlb.WorkflowLogId
   join @DeletedAsyncRowsTable dart on
    wlb.AsyncOperationId = dart.AsyncOperationId
 delete WorkflowLogBase from WorkflowLogBase W, @DeletedAsyncRowsTable d
 where 
  W.AsyncOperationId = d.AsyncOperationId             
 delete BulkDeleteFailureBase From BulkDeleteFailureBase B, @DeletedAsyncRowsTable d
 where 
  B.AsyncOperationId = d.AsyncOperationId
 delete WorkflowWaitSubscriptionBase from WorkflowWaitSubscriptionBase WS, @DeletedAsyncRowsTable d
 where 
  WS.AsyncOperationId = d.AsyncOperationID 
 delete AsyncOperationBase From AsyncOperationBase A, @DeletedAsyncRowsTable d
 where 
  A.AsyncOperationId = d.AsyncOperationId
 /*If not calling from a SQL job, use the WAITFOR DELAY*/
 if(@DeleteRowCount > @rowsAffected)
  return
 else
  WAITFOR DELAY '00:00:02.000'
end

EDIT: 26-February-2015;
1: Support article code was updated for a more smooth execution.
2: Added required retention time on records of 1 month;