Have you decided on the Sitecore content management system to deploy your company website? Great choice! As a .NET architecture, there are a few things your developers should keep in mind when it comes to performance, scalability and security.

Sitecore’s robust .NET based architecture is a huge advantage to teams deploying the product. The speed of development and the configurability of the platform allows for amazing results in a very short time. Conversely, the ever expanding scope of the platform has led to a plethora of settings and configurations that may need adjustment for production environments to ensure scalability, security and performance.

Drawn from NLC’s project experience and a host of Sitecore documentation we have assembled this list to help guide you in those steps.

Getting Started – Sitecore and IIS

If you use the executable to install Sitecore, many of these settings are adjusted automatically however that can change from release to release and on some occasions; specific policies on the server may prevent the installer from modifying the configuration.

  1. Set permissions on /website and /data
  2. Ensure the data and indexes folders are outside of the web root and update the web.config to point to the data folder
  3. In IIS ensure that Maximum Worker Processes for the Application Pool is set to 1 (under advanced settings)
  4. In IIS ensure that Load User Profile settings of the Application Pool is set to "true" (under advanced settings)
  5. In IIS ensure anonymous access is denied for:
    /App_Config
    /sitecore/admin
    /sitecore/debug
    /sitecore/webservice
  6. In IIS Enable HTTP keep alive
  7. In IIS enable static content compression
  8. In IIS on the CMS server, enable dynamic content compression
  9. In IIS disable execute permissions on the upload folder
  10. In IIS enable content expiration using HTTP response headers, especially for the /sitecore folder (optional)

Unlock the power of the xDB

A look at a day in the life of a Sitecore marketer

Get the whitepaper

 
Sitecore Configuration Changes

  1. Ensure the /data and /indexes folders are outside of the web root and update the dataFolder setting to point to the data folder.
  2. Include the path to static media files (header images, css files, JavaScript files) in the IgnoreURLPrefixes settings to prevent Sitecore from intercepting the requests.
  3. Disable unused search indexes by setting Indexing.UpdateInterval to 00:00:00.
  4. Update the standard cache sizes for prefetch, data, item and item as recommended (see the scaling guide), and then test for further adjustments.
  5. Ensure presentation components that are candidates for caching are set to cacheable.
  6. For 64-bit systems with the available memory, disable cache size limits using Caching.DisableCacheSizeLimits.
  7. Disable performance counters using Counters.Enabled as they add overhead.
  8. Disable WebDav by removing the references in <log4net/>, <system.webServer />, <httpHAndlers>.
  9. Disable memory monitor by removing the hook from <hooks />.
  10. Restrict access to .XML, .XSLT and .MRT files using the <system.webServer><handlers> section.
  11. Disable the upload watcher by removing it from the <system.webServer><modules> - Sitecore.Resources.Media.UploadWatcher.
  12. Optionally disable client RSS feeds by removing the Sitecore.Shell.Feeds.FeedRequestHandler.
  13. Remove unneeded headers from the responses.  For example X-Aspnet-Version, X-Powered-By, X-AspNetMVC-Version.

Sitecore Databases

Some simple adjustments to the configuration of SQL Server can greatly improve the performance of the database environment.  Keep in mind that some of these settings may impact the backup approach you employ for MS SQL.

  1. Set the compatibility level to SQL Server 2008 (100) to take advantage of the latest optimizations.
  2. Ensure the auto close property is set to false. This ensures that a page will only make one connection.
  3. Ensure the auto shrink property is set to false to avoid costly dynamic resizing.
  4. Ensure the recovery model is set to simple to avoid the high overhead of transaction logs.


comments powered by Disqus