Performance Planning

This chapter describes how the performance of solutions running on MatchPoint can be improved. From an architecture perspective, MatchPoint is running on SharePoint whose performance is highly related to the SQL Server. Following are some recommended improvements, most of them documented by Microsoft as well.

SharePoint perspective

The Disks and the NTFS Allocation size

  • Running SQL Server on SSD
  • change the NTFS Allocation size of your drives by formatting the disks
    • SQL reads and writes 64K at a time, but your disk allows only 4K by default. This change alone may show you up to 30% improvement in speed.
  • Please check from time to time the available disk space to avoid system failure.

    Modifying the Model Database to increase SharePoint performance

  • Initial size & Auto Growth
    • The modelDB’s initial size and autogrowth should be in megabytes and set to a value larger than the default. Don’t use the default settings.
  • This will help performance, as SQL won’t have to constantly ask for more space to store data.
  • You should do the same changes to your TempDB SQL Database as SharePoint also uses it indirectly through the database server to store objects.
    • Testing and customer data show that SharePoint Server farm performance can be significantly impeded by insufficient disk I/O for tempdb. To avoid this issue, allocate dedicated disks for tempdb. If a high workload is projected or monitored — that is, the average read action, or the average write action requires more than 20 ms — you might have to ease the bottleneck by either separating the files across disks or by replacing the disks with faster disks
    • TempDB Files Configuration
      • The number of tempdb files should be the same as the number of processor cores present on the SQL server. If the number of logical processors is greater than 8, use 8 data files and then, if contention continues, increase the number of data files by multiples of 4. Additionally, all file sizes should be equal.

        Distributed Cache - Cache Size

  • Microsoft recommends that the cache size of the Distributed Cache service is set to 10% for servers in collocated mode or per the following formula for dedicated servers: (total physical memory on server - 2 GB for other processes and services that are running on the cache host)/2. Deviation of 10% is acceptable. Maximum memory allocation is 16 GB.
  • Microsoft does not recommend that any Search, Excel and Project Server services or applications run on the same server as the Distributed Cache service.

    IIS Log Path

  • Log files (both ULS and IIS) should not be on the primary drive, as their usage pattern (write-intensive) can impact server performance.

    SharePoint CU

  • Should be kept updated to the latest version compatible with the product.

    Caching

  • Blob Caching Enabled
    • recommended in a single WFE Farm
  • BranchCache Enabled
    • recommended for an organization that has two or more physical locations and a wide area network (WAN) connection from the branch offices to the main office.

      Implement HTTP2

  • HTTP/2 is a rework of how HTTP semantics flow over TCP connections, and HTTP/2 support is present in Windows 10 and Windows Server 2016. HTTP/2 is a major upgrade after nearly two decades of HTTP/1.1 use and reduces the impact of latency and connection load on web servers.

MatchPoint perspective

DataProvider caching can be enabled from configurations

  • Cache Granularity
    • Caching per User, can overload the server memory allocation/performance, some cached data might make more sense to be cached Global instead, to reduce the server overload and the User cache expiration 'issue'.

      Refiners

  • Refinements aggregates the search results, so as more results we have more heavy is the refinements aggregation. With this, more refinements we have more heavy will be the page load. It will help the performance if an analysis could be made on which refinements are strictly required and how many elements can/should be displayed.
    • Make sure NativeRefinementSettings are enabled on all CompositeRefinementWebPartConfiguration. If enabled, native refinement support (if available) is used, otherwise the full result set is analyzed. Note, that this might change the refinement behavior, since refiner conditions are extracted from the Conditions tree by the data provider and are applied separately.

      Warm-up script

  • Use a warm-up script that will iterate through most used pages

    Disable Minimal Download Strategy Feature

  • MatchPoint components can be used in MDS compatible Master Pages and ASP.Net Pages. MatchPoint controls do not use MDS and are not MDS compliant as they use their own asynchronous loading strategy. An improvement in loading times of SharePoint pages with MatchPoint Controls can be achieved situatively, i.e. depending on the master page and the way the MatchPoint components are used, by disabling the MDS feature.

    Planning Environments with many workspaces

    • If you are planning to setup an environment with more than 5000 workspaces, it is advisable to switch to a search based aggregation mode due to the default list view threshold. For more information please refer to Environments with many workspaces.

Sources

ShareGate blog - Improving SharePoint performance

Technet Performance Page on SharePoint

Inside SharePoint Improving SharePoint Performance

Hardware and software requirements for SharePoint

[book] The Ultimate SharePoint Performance Guide!: Configuring SharePoint, SQL and Office 365 for maximum performance

[app] SPDocKit analysis

CYCL infrastructure team analysis

results matching ""

    No results matching ""