SharePoint Performance (On-Premises)

A - OBJECTIVE: this article aims to

1. Analyze factors to be considered to boost SharePoint performance
2. Present a systematic approach to troubleshoot on-premise SharePoint platform. 

B - PROBLEMS :

SharePoint sites & their hosted applications may experience the unusual slow page response.

The duration from the time a user clicks the link to the time the page is fully loaded will have 3 stages:

1. Server time: the time required for the request to communicate with the server.
2. Network time: the time required to transfer data through the network
3. Browser time: the time required to render the page at the user’s browser 

By integrating Google Analytics (GA) into your SharePoint sites, you will be able track these interesting statistics pertaining to the loading time of a page. 

The good points about this approach are :

• Statistics of response time is captured automatically daily.
• A comprehensive usage analysis at your sites will be available by default.
• It is free to use GA.

For instance, we tracked the loading speed of a landing page of a SharePoint site through several months as follows:



C - SOLUTION:

As a guideline, the following matters should be checked after you drilled down the performance issues to a certain type (Server, Network, or Browser): 

1. At Infrastructure level:

• Virtual Machines (VM): if VM is used in your SharePoint environment, these points should be checked:
• The ratio of virtual processors (VP) to logical processors (LP) should be VP:LP = 1:1  (reference here)
• RAM should be sufficient compared to the size of content database (reference here).
• The available space at operating drives (e.g. C drive) should be at least as thrice as the RAM capacity in the server. 
• Network across multiple offices: should be measured to find out the blind spots (merely by using Ping & Trace)
• Network Load Balancer (NLB) can be used to share the traffic load.
• Disk Monitoring: should be tracked to avoid the incident of full disk.
• Other programs at your PC (e.g. Anti-Virus) can increase the loading time at your browser. 

2. At Database level:  

• Connectivity between web frontend servers & database servers
• Database IOPS rate 
• Multiple Content Database should be planned to anticipate the data growth & to align with the recommendation of max 200GB per content database.

3. At SharePoint level:

• Search Crawling & Indexing jobs : should be scheduled during off-peak times.
• Health Reports: should be checked & cleared.

D - BENCHMARKS:



To be updated.

Office 365 - Workflow Performance

A - OBJECTIVE: 

- Online workflow services provided by Office 365 have some drawbacks in terms of performance & resources.

- We will aim to address all workflow performance in this post.

B - PROBLEMS :

PROBLEM 1: infinite loop

1. Error Message: The runtime has detected an infinite loop in the instance after allowing 30000 milliseconds of CPU without an idle point.




2. Reason: 
- Loop is done repeatedly while indexItem is less than countItems. Based on the test, If the counteItems is less than 200, it works fine till the end. However, if it's larger than 200, normally the instance is suspended.



- When the runtime detects such kind of loop, which has high consumption of CPU and memory, it will suspend the instance. 

- The limitation is controlled by a complicated formula which depends on multi-dimension factors, such as CPU consumption, memory consumption, workflow complexity, etc.

- Such limitation exists to ensure high performance of workflow service and prevent attach and malicious code.

3. Solution: 

- If the Workflow is complex and redesigning it is not an option, as a short term fix, it is best to leverage the Pausing capabilities, of the Workflow. It is simple but can keep the Workflow, from getting throttled. 

- Pause for Duration or Pause Until Date can simplify this design. For this case, you may process 100 items then pause the instance for a while (i.e. 15 mins).

4. Source Code: