Brandon Bowlin / / Categories: Best Practices, Technical View, SharePoint/OneDrive

Top 3 Ways to Improve SharePoint Performance

SharePoint is one of the most widely adopted and fastest-growing Microsoft products.  What may have begun as a simple implementation for a single workgroup can balloon into usage for the entire organization, all vying for SharePoint resources.  As SharePoint grows, maintaining optimal performance is vital for continued usage and adoption.

Specifically geared to on-premises SharePoint implementations, below are Enabling’s top three recommended best practices to boost performance of your SharePoint environment.

Separation of Services:

A typical SharePoint farm consists of web front-end (WFE) servers, application servers and SQL servers; all hosting a variety of services for the functioning of SharePoint.  Organizations will try to minimize the number of servers by combining services, often sacrificing performance in the process. 

At a minimum, search indexing should always be isolated from other servers performing the application role.  Search traffic generated by the index server must be processed by the servers delivering content.  A single server both querying content and generating results may delay search results and negatively impact users.

To obtain even better performance, load-balanced servers should be used at each tier of the environment (i.e. multiple application servers, multiple WFE servers, etc.).  Not only does this spread the load of users of accessing servers at any given time, it also provides for better redundancy in the event of a server failure.

SQL Database Parameters:

All SharePoint farms utilize SQL databases for storing content and processing information.  As such, SQL may also be a bottleneck if not properly managed.  A few simple changes to default configurations can greatly enhance performance.

  • Pre-grow databases
    • Require more space initially
    • Dramatic increase in performance
    • Databases like contiguous space
  • Auto-growth
    • Do not use “Grow by %”
    • Change from 1mb increments
    • Schedule maintenance tasks to check size and grow in off-peak hours
  • Content Databases
    • Recommended limit is 200GB (can be 4TB in certain situations)

Planned Customizations:

When customizations are deployed to SharePoint, entire content and code bases are stored in the databases and are retrieved each time a page is requested.  To keep poorly written code can cause an overload on the database and reduce its performance: 

  • Test, test and test again to determine tolerance for custom solutions
  • Require that the SharePoint Dispose Checker Tool (SPDisposeCheck) but used before deploying any custom solution
  • Install and test all custom solutions in a Dev/QA Environment, then you don’t “really” have a Prod environment
  • Never test SharePoint patches in Production as they may impact custom code in unknown ways
  • Never accept non-wsp / non-packaged solutions


SharePoint is an extremely powerful application with endless capabilities and addressing performance before it becomes a problem is the best way to keep it running optimally.  Pre-planning and addressing gaps in advance saves time and money in the future.  If you’d like to know more about SharePoint best practices and have your own environment reviewed for performance-impacting gaps, contact Enabling today to sign-up for a Health Check today at!/SharePointOneDrive/SharePointHealthCheck.aspx


Work with our team of Cloud Computing Consultants who have done this so many times they know all of the “minefields” to prevent missteps.