Managing Sharepoint Performance At Scale

Identifying Performance Bottlenecks

Analyzing usage patterns across the SharePoint infrastructure can help identify areas that experience high user loads which may cause bottlenecks. Monitoring key metrics like page load times, database query response times, and server resource utilization can pinpoint potential problems.

Examining web server logs, database query profiles, and performance monitor data can provide insight into the underlying root causes impacting user experience. Slow page loads may indicate insufficient web front end capacity, complex custom page rendering, or unoptimized database queries. High database server CPU usage could signify lacking indexes or inefficient data access code.

Analyzing Usage Patterns to Pinpoint High Load Areas

SharePoint provides usage analysis tools to report on metrics like most active sites, pages with the most hits, and highest contributing users over custom time periods. Site collection administrators can break down usage data by site, list, library, or page to isolate those experiencing the heaviest loads.

Third-party SharePoint performance monitoring software similarly lets administrators examine usage trends across a farm, drill-down into which site collections or pages generate the most user traffic during peak times, highlight tedious database queries called frequently during user actions, and correlate usage with infrastructure capacity metrics.

Monitoring Database Queries and Page Load Times

SharePoint dynamically generates much of its content from the backend SQL Server databases powering site collections, libraries, and lists. Performance issues often arise when improperly indexed database schemas lead to slow responding complex queries under load.

Capturing database profiles during peak usage helps uncover long running, repetitive queries that may benefit from indexes to speed up response times. Database tools like SQL Server Profiler can record query text, duration, and calling code stacks over time to pinpoint optimization targets.

Correlating slow page load times reported in the SharePoint logs with heavy queries logged in the database profiler indicates if DB performance tunings like indexes could improve user response times.

Checking Resource Utilization Across Servers

Page load delays and throttled site performance may have their root cause in overloaded front end web servers unable to keep up with user demands. Conversely, sluggish database query responses blaming overly complex queries may actually stem from excessive CPU or memory constraints on database servers.

Monitoring utilization metrics like CPU usage, memory consumption, disk I/O, and network traffic across both front end SharePoint and backend SQL nodes can confirm where resources become saturated under peak loads. Identifying capacity limitations is key toward right-sizing farms to maintain snappy performance as usage scales up.

Scaling Out SharePoint Farms

When usage analysis pinpoints heavy user loads stemming from exhausting existing web front end or database capacities, expanding the resources available to SharePoint through scale-out methods can help alleviate bottlenecks.

Adding Web Servers to Support More Concurrent Users

SharePoint farms generally utilize a small pool of initial front end web servers, like 2-5 nodes, which host sites and service user requests. Monitoring shows at what thresholds this web capacity proves inadequate during surges in active visitors, evidenced by sluggish performance or timeouts.

Scaling out web capacity directly accommodates hosting larger volumes of simultaneously active site collections and servicing higher numbers of concurrent user requests without performance degrading once additional nodes come online.

Load Balancing Across an Expanded Application Server Pool

Application servers within SharePoint farms run critical services like search, metadata caching, and custom software shared across sites. Concentrated usage of these services can overconsume the limited app server resources available in starter farms.

Expanding the application server pool and load balancing usage across a wider set of nodes prevents the same subsets of servers from becomingbogged down. Service applications also benefit from scaled-out capacity and balanced request distribution.

Partitioning Service Apps Across Multiple Servers

Certain SharePoint service applications like Managed Metadata can suffer reduced performance when the entire farm’s taxonomy and metadata tagging needs route through a single database. The heavy queries and updates concentrate load excessively.

Configuring service apps like Managed Metadata and Search to provision multiple database backends allows partitioning data across servers. This divides query demands across nodes instead of overwhelming singular servers when usage scales up.

Optimizing Database Performance

Tunings that remove data access inefficiencies or excess overhead from database operations can optimize SharePoint performance regardless of current scale. Indexes, archiving, and read-only reporting databases present options to streamline databases.

Indexing Columns Frequently Used in Search Queries

SharePoint list data constantly shifts as users add, edit, and remove items. Ad hoc views also query and filter datasets in unpredictable ways. Missing database indexes leads to slow responding search results or library views as the database scans entire tables.

Identifying the most common columns targeted by search criteria and view filters then applying appropriate indexes significantly speeds returning indexed data versus scanning entire database tables each query.

Archiving or Removing Unused Site Collections and Content

Over time, some SharePoint sites and libraries accumulate huge data volumes across countless items despite dwindling actual usage. User farms storing terabytes of infrequently accessed content unnecessarily bloat the databases queried during routine searches.

Archiving stagnant sites and document libraries to cheap external storage or purging obsolete entries entirely offsets content database sizes. Leaner databases then require less compute for queries and infrastructure for hosting.

Enabling Read-Only Reporting Databases

Decision makers often utilize SharePoint usage reports, audit reports, or third-party business intelligence tools to extract operational analytics from the platform. Executing complex read reporting queries against production databases with continual user activity and updates often cripples performance.

Provisioning dedicated, read-only SharePoint reporting databases that restore updated copies of production data on schedule allow analytics queries to run without impacting mainstream user database efficiency.

Leveraging Caching and Content Delivery Networks

Caching and content delivery networks (CDNs) shift static resources closer to users and skip redundant generation work through saved copies. In SharePoint’s context, caching and CDNs apply best for static files, rendered page output, and external media content.

Configuring Caching for Static Assets and Pages

SharePoint page construction relies on core static files stored in the /Layouts virtual path plus styling assets found across /Style Library folders in sites and site collections. Without caching, requesting pages repeatedly access these files from disk.

Server-side caching mechanisms like SharePoint’s object cache or the Windows server cache store these static files in memory to avoid repeatedly hitting the disk. Page output caching also prevents re-rendering page markup and layouts on each request.

Offloading Media Requests to a Cloud-Based CDN

Document libraries in SharePoint store user-uploaded images, videos, PDFs and other media as BLOBs within SQL content databases. Downloading these files requires querying the database and passing through SharePoint servers.

Integrating a cloud-based CDN allows pushing media content from SharePoint storage into a geo-distributed caching network. Serving files directly from CDN edges skips taxing infrastructure while accelerating delivery.

Caching Source Data Calls via Intermediary Services

Custom SharePoint solutions often query or post data into external systems like ERP applications or Line-of-Business systems. These external service calls while rendering each page introduce performance lag spinning up connections.

Caching frameworks like Redis and Memcache provide intermediary data stores to buffer external system queries and responses. Subsequent page loads fetch needed data from the speedy cache without re-querying integrated apps.

Proactive Performance Monitoring

Reacting to SharePoint slowdowns only after users feel impact means performance issues already degraded experience. Proactively monitoring key usage metrics provides opportunity to get ahead of emerging problems.

Setting Alerts for Critical Performance Indicators

SharePoint and SQL Server provide verbose performance counter tracking usage stats like memory consumption, CPU usage, and disk queues across servers. Performance Monitor exposes these metrics.

Establishing threshold-based alerts tied to key usage indicators provide early warning when resources trend toward exhaustion, before capacity bottlenecks trigger performance problems.

Finger on the Pulse With Centralized Reporting Dashboards

Monitoring usage data in real-time quickly loses context unless tracking long-term trends. Gauging if current load traces expected peaks or exceeds performance baselines requires historical perspective.

Dashboards plotting SharePoint, SQL, and hardware metrics over time supplement alerts for operators managing scaling and capacity planning. Graphical reports also aid identifying seasonal traffic patterns to plan growth.

Determine Performance Budgets by Establishing Baselines

Every SharePoint farm and infrastructure combination delivers varying degrees of performance based on sizing, configuration, and usage profiles. Comparing metrics against industry rules of thumb lacks custom relevance.

Track response times, throughput limits, and utilization under modeled use cases and projected loads. These measured baselines quantify expected performance budgets for current environments to guide upgrade timing.