Outdated database statistics decrease SharePoint Server performance, cause time-outs, and generate run-time errors

Hello All,

After many performance issue investigations,  we have released at 10th of October 2015  following kb article for about “Outdated database statistics decrease SharePoint Server performance, cause time-outs, and generate run-time errors”

In this article scope we make availability and  some flexiblity for database maintenance operations about  preventing “outdated update statistics” for DBAs , and now you are not depending just only SharePoint Daily Timer job which responsible update database statistics by using the proc_updatestatistics SQL procedure anymore.

Our TechNet article “Best practices for SQL Server in a SharePoint Server farm” has now been updated with the same guidance and cross referencing the new KB article.

Do not enable auto-create statistics on a server that hosts SQL Server and SharePoint Server. Enabling auto-create statistics is not supported for SharePoint Server. SharePoint Server configures the required settings during provisioning and upgrade. Manually enabling auto-create statistics on a SharePoint database can significantly change the execution plan of a query. We recommend updating the SharePoint content database statistics daily using the FULLSCAN option from SQL Server. Although SharePoint does have a timer job to update statistics by calling proc_updatestatistics, we strongly recommend implementing a scheduled maintenance plan from SQL Server to ensure database statistics are reliably updated on a daily basis. For more information, see Outdated database statistics.

Best practices for SQL Server in a SharePoint Server farm

Now ; to prevent  potential service outages, SQL Server maintenance plans can be implemented to keep SharePoint content database statistics updated by using the FULLSCAN option and it can be done manually by DBAs

When implementing the SQL Server maintenance plan to update the statistics on your SharePoint databases, it is not required to disable the job from SharePoint. However, because these maintenance tasks perform similar functions from both locations, it is permissible to disable the timer job from the SharePoint farm.

About SharePoint 2013 Virtualization and Best Practices

Best Practices

  • For the highest level of performance, configure a VP:LP ratio of 1:1 for any virtual machine that is used in a SharePoint 2013 farm. Remember that oversubscribing the CPU on the physical host used for virtualization can reduce performance.
  • For optimal performance of demanding workloads, run Windows Server 2012 Hyper-V on SLAT-capable processors/hardware. This offers the additional benefits of improved performance, greater virtual machine density per host machine, and reduced overhead as compared to non-SLAT systems.
  • When you are planning how to use the host server’s memory, it is important to consider the virtualization-related overhead. Whether you choose to use NUMA or Dynamic Memory, both have some overhead related to memory management in the virtualized environment. In the case of SharePoint environments, Microsoft does not support the use of Dynamic Memory, or technologies similar to Dynamic Memory found on alternative hypervisor platforms. This is because certain features of SharePoint can suffer from performance degradation when Dynamic Memory is enabled. For example, the cache size for the Search and Distributed Cache features are not resized when the memory allocated to the virtual machine is dynamically adjusted.
  • In most production SharePoint Server deployments, we recommend that you have at least 8 GB of RAM on each web server. Capacity should be increased to 16 GB on servers that have greater traffic or deployments with multiple application pools set up for isolation.

In Summary  : I am always sharing following rule with our customers ;

“The Golden Rule for SharePoint 2013 Virtualization” : Configure your virtual machines like a Physical Machine with all dedicated resources ( CPU,RAM,HDD etc.)  for any hypervisor platform and avoid shared Resources.

Heads up are you still using SharePoint 2010

I want to spread my colleague Stefan’s post for this important headsup:

Mainstream support for SharePoint 2010 will end on October 13th, 2015:

After this date only security fixes will be provided for SharePoint 2010. That means if you are running into an issue after October 13th which is caused by a problem in SharePoint 2010 and which has not already been addressed before you will no longer be able to request a hotfix.
Not the best situation if you are using SharePoint 2010 as a business critical application.

There are still three months till deadline – enough time to evaluate SharePoint 2013 and consider an upgrade.


Technet Distributed Cache Articles are updated !

Heads up , Technet Distributed Cache Articles are updated !

Plan for feeds and the Distributed Cache service in SharePoint Server 2013

Microsoft has updated the following sections:

• Capacity planning for the Distributed Cache service
• Memory allocation

The memory issues have been noted here. Now we are requiring at least 34GB of memory for 16Gb Cache Servers. If more than 16GB’s are required, we now require at least 2 cache servers

Manage the Distributed Cache service in SharePoint Server 2013

Microsoft has updated the following section:

*Fine-tune the Distributed Cache service by using a Windows PowerShell script
*Changed the Graceful Shutdown procedure

In the “Fine-tune the Distributed Cache” section we called out the MaxConnectionsToServer issue and have a script to tune these settings. We are also tuning the “DistributedLogonTokenCache” and “DistributedViewStateCache” as the defaults are too small.

This should eventually eliminate many support cases that occur after customers follow bad advice from random Blogs and utilize default settings.

Do we really need a Load Balancer between Workflow Manager Farm and SharePoint ?

Well , It  depends .

If you have a Workflow Manager farm (more than one server) and one of the WFM EndPoints recieve a request without any load balancer ,it balances the load across the WFM servers .Yes thats correct . WFM farm have an internal load balancing mechanizm to do that.


But if you don’t use a load balancer ,WFM only balance the load , not switch between endpoints if active endpoint dies . There is only one endpoint be active at a time . And if something happens on that EndPoint or its host machine then you may face an outage even your other servers are alive. Because SharePoint knows only one endpoint url and it is not reachable.

So it depends that how much you want a high availability . Actually in real , load balancer is resposible not to share load , just keeps high availability if an endpoint dies  between your SharePoint farm and WFM farm .

Using EF in SharePoint read this first

Entity Framework (EF) is one of the best framewok that i love , it makes data layer things quicker,safer and better for us. Well using Entity Framework inside of SharePoint (i mean in same worker process) ,if you not expert level experiance enough with EF and don’t know what you do ; using it in SharePoint is not a good idea , SharePoint itself is a huge web Application ever developed even you did not make any customization. Billons of code and hundreds of assemlies are behind in a simple SharePoint site   And any integration using EF ( except small implementations) If you make easily something wrong or not calculate the data grow you must highly face a performance issues. And trying to troubleshoot it inside the sharepoint it is not an easy task.

A highly utilized SharePoint site, has already consume many of your system Resources , even out side of the SharePoint , an ASP.Net Application using EF can easily comsumes your resouces .(Yeah it depends what you do) . both heavy Operations in same place is not a wise decision .

For SharePoint 2010 it is not posible. SharePoint 2010 based on the .NET FrameWork 3.5, which requries IIS to use the ASP.NET 2.0 Runtime. Entity Framework 4.1 or higher builds uses the .NET FrameWork 4.0, which requries IIS to use the ASP.NET 4.0 runtime. As a result you cannot run EF 4.1 or higher builds natively in SharePoint 2010.

For SharePoint 2013 use .NET framewok 4.0 , and there is no restriction to use EF inside SharePoint 2013 processes. But you really want to use it , i would suggest do it out side of the SharePoint . Create a WCF/Web service  and use your data logic , caching etc outside of the SharePoint and consume it from SharePoint side .It will provide you flexibility , compatibility ,stability and easy troubleshooting if you face any problem.

Well , Microsoft makes all investments on cloud Technologies and the SharePoint Online is our future , you could not use any Server OM tools with SharePoint Online , Unfortunately EF implementation inside SharePoint included , so if you have any kind of EF implementation inside SharePoint will not be supported for SPO if you have any plan for migration .

IE11 “edge” mode is not supported for SharePoint 2013 and 2010

OOB SharePoint pages use special tagging to explicitly avoid this mode – however who want to enable it or just wrote custom master pages where they did not disable it (Edge is the preferred document mode in IE11) may face the problems.

For SharePoint 2010:
Plan browser support (SharePoint Foundation 2010)

For SharePoint 2013:
Plan browser support in SharePoint 2013

it is not supported to use SP2010 or SP2013 with Internet Explorer 11 in Edge mode. Resolution is Add sites to the Compatibility View list to make some features work.