This document is a collection of diagnostic procedures, tuning procedures, and Sitecore recommended practices for getting the optimal performance out of your Sitecore implementation.

A must read for anyone using Sitecore!

Web Performance Load Tester is a powerful and easy to use tool that will allow you to automate load testing and generate reports to help you analyze the performance of a web site.

The 10 virtual user version, which is full featured, is free to use and is ideal for identifying pages that exceed a threshold value for further investigation.

Setup

Web Performance Load Tester can be downloaded from Web Performance Load Tester. Once downloaded, follow the defaults to install.  No key is required for the 10 virtual user version.

It is highly recommended to view the online demos that are available at Online Demos to get and understanding of the capabilities of the tool.

How to use Web Performance Load Tester.

To Launch Web Performance Load Tester:

1. Locate the Web Performance Load Tester item in the Start menu and click to launch.

When you launch Web Performance Load Tester, the interface will look similar to what is shown above.

Each of panes can be minimized, maximized, hidden or removed to accommodate who you choose to display information.

A quick overview of the panes (not all panes shown):

1. Navigator View – shows the contents of each open repository.   Double-click repository items (or select a testcase and choose Edit from the pop-up menu) to open it in an editor.
2. Toolbars – provides shortcuts for the most commonly used features.
3. Editors and Charts – Displays recorded test cases as a tree of pages and URLs, dataset editor for displaying and editing datasets, and report details.
4. Detailed inspection views:
   Content View – renders the content of web pages
   Headers view – displays HTTP request and response headers
   Errors view – lists any errors encountered during the recording or replay of a testcase
   Replay view – indicates the status of the replay in progress
   Fields view – displays the HTTP fields that can be associated with modifiers
   Servers view – displays CPU and memory usage metrics for the specified machine
   Engine view – display CPU and memory usage metrics for the client machine
   Metrics view – displays detailed metrics for the current load test.
5. Status View – displays the status of long running operations, such as recording and playback.

Setting up Web Performance Load Tester and IE to record web sessions

Web Performance Load Tester is setup by default to launch your default browser once the record button has been clicked.  However, if your computer is using a VPN connection you will receive a proxy error when trying to record.  To avoid this, we are going to setup Web Performance Load Tester to not automatically launch the default browser.  We will also setup the proxy configuration manually on our browser to force the traffic through Web Performance Load Tester.

Disable auto launch of web browser:

1. With Web Performance Load Tester opened, click on Window -> Preferences
2. Expand Web Performance and click on Recording.  Make sure that “Launch default browser when recording” is unchecked.  Also, make note of the HTTP and SSL recording ports since they will be used when setting up our proxy ports on our web browser.
   
   

Setup IE to use proxy:

This example uses IE8.  Setting up other browsers to use a proxy follow similar steps.

1. Launch IE
2. Click on Tools -> Internet Options and click on the Connections Tab
   
3. Click Settings
   
4. Check “Use a proxy server for this connection and click on the Advanced button.  Note, once you create the proxy settings you can enable and disable the use of the proxy by selecting or clearing the “Use a proxy server for this connection” check box.
   
5. Set the proxy address for both HTTP and Secure to 127.0.0.1 and set the ports to those that we pulled out of the Web Performance Load Tester Recording dialog.
6. Click OK, OK, OK to exit the IE settings.  You are now ready to record web sessions.

Creating a Testcase

The following steps show you how to create a testcase with Web Performance Load Tester.  The testcase can either be evalutated, once complete, or be replayed with up to 10 virtual users over a time span.  For detailed information on how to interpret the results, please go to the online videos available at: Online Demos, as well as review the built-in help.

Creating a testcase:

1. Launch Web Performance Load Tester.
2. Click on the record button in the Toolbar
   
3. Launch IE, making sure that the “Use a proxy server for this connection” checkbox is checked (see details above).
4. In your browser, go to the site that you want to record and start clicking around the site.  The idea is to hit as many layouts and possible rendering combinations as possible.
5. When you have sufficiently navigated around the site, return to the Web Performance Load Tester and click the stop button to end the recording
   
6. The Editors and Charts pane will show the results of your recording:
   
   The recording will show you the title of the pages visited, the size of the page, the duration required, a time goal to compare the duration to (can be changed in the preferences), think time while on the page, status code as well as the URL of the page. 

   Also, each page can be expanded to show the components (files, images, etc) that make up the page, as well as the size and duration for each component.

7. From here you can review the results in a detailed report, replay your existing recording with or without think times, and /or set up a load test with up to 10 virtual users.

There is a lot of information that can be had by analyzing what takes place when a web page is loaded into a browser. Not only information about what is being requested, time to response, size of objects, etc., but also how the server is setup in terms of caching, compression, CDN usage, and keep-alive information.

This postings looks at using an open source plug-in, AOL Pagetest, along with how to interpret the results.

Setup

The AOL Pagetest browser plug-in can be downloaded from: http://sourceforge.net/projects/pagetest/files/

Once it has been download, install in its default location. The AOL Pagetest plug-in works with IE 7+ browsers, and will appear in the Tools menu. (Note: If IE was opened up during the install, you will have to restart IE for the AOL Pagetest to appear in the Tools menu.)

How to use the AOL Pagetest browser plug-in.

To launch the AOL Pagetest:

1. Launch IE.
2. From the Tools menu, select AOL Pagetest . A blank screen will appear with a single empty tab (Waterfall).

Capturing Information:

There are 3 useful page loading scenarios that will be gathered during this exercise to see how the web page reacts to a cleared browser cache, a page reload, and a page request with a loaded cache.

• Cleared browser cache – This will simulate the first time a page has been visited from the browser being used.
  • To clear the browser cache for IE 8 and above:
    • From the Safety menu, click Delete Browsing History…
    • Deselect Preserve Favorites website data, and select Temporary Internet Files, Cookies, and History
  • To clear the browser cache for IE 7:
    • From the Tools menu select Internet Options
    • Under Browsing History, click Delete…
    • To delete you cache, click Delete files…
    • Click Close, and then click OK to exit.
• Page reload or refresh – This will force requests to be made to cached objects, resulting in 304 status codes. When a 304 status appears, a request is still made for an object, even though no download occurs.
• Accessing a recently visited page (typing in the URL) – This will result in a page with a much reduced request chain, since items that were previously loaded into the browser cache will be accessed without making any requests.

First Pass – Cleared browser cache:

1. Launch IE.
2. Clear the browser cache (see above).
3. Launch AOL Pagetest.
4. Type in the URL you wish to test (for example: http://www.sitecore.net)
5. The AOL Pagetest window will now show 4 tabs (Waterfall, Checklist, Optimization Report, and Load Details). How to interpret the information presented in each tab will be discussed below.
6. Observations from this view include:
   1. Notice that the Waterfall view shows a full request made to each object in the webpage.
   2. That assets such as CSS and JS files have not been combined, so multiple requests are being made to download them.  By combining all of your CSS and JS files, the time line will be pushed to the left, due to a single request being made, shortening the time to render the page.

Second Pass – Refresh browser page:

1. From the AOL Pagetest File menu, select New
2. Refresh the browser page (click on the refresh page icon, or hit F5)
3. Only the results of the Waterfall Tab are shown as a means to present the differences from the first pass.
4. Observations from this view include:
   1. The objects highlighted in yellow are 30x status codes.
   2. The results below show that cached items are requested, but not downloaded.  This is expected behavior for a page that has been refreshed.
   3. What can be taken from this view is that those items with a 304 status code should not be requested during the 3rd pass, “A recently visited page”.

Third Pass – Recently visited page:

1. From the AOL Pagetest File menu, select New
2. In the browser select the URL and hit enter (do not click on the browsers refresh button).
3. Only the results of the Waterfall Tab are shown as a means to present the differences from the first and second passes.
4. Observations that can be taken from this view include:
   1. The request tree has been reduced significantly.
   2. It is known that the first two requests, / and visitor.css, are dynamic and not cached.
   3. The third item requires investigation as to why it is not coming from cache. Upon further investigation it was found that this request is a rotating image, which changes across visits. (OK not to be in cache).

Interpreting the results:

Here we will dive into the Waterfall, Checklist, Optimization Report, and Load Details tabs, explaining the information that is presented.

Waterfall Tab

The Waterfall tab presents a view of the request chain that makes up the requested objects for a web page. The requested objects are listed down the left side, and the time is listed along the top.

The colors that make up a request / response are:

• DNS Lookup – This is the time it takes to look up the IP Address for the requested URL.
• Initial Connection – This is the time that it takes to go from the client to the server to open up a socket. Note, if an initial connection is made on every request, this could be an indication that the HTTP keep-alive has not been enabled on the server.
• Time to First Byte – This is the time that it takes from request to receiving the first byte of the object. Extended Time to First Byte times could be an indicator of a problem at the server (i.e. performance issues), or network issues.
• Content Download – This is the time required to download an object. Extended Content Download times could be an indicator of large objects. An inspection of the size of the object may be required. For example: images that have not been optimized or compressed could have an effect on the performance of the web page.
• Start Render – This is the green vertical line shown on the Waterfall. This indicates when the user starts to see content appear in the browser. Technically this represents the time when the web page has a height and width > 0.
• Document Complete – This is the time when the document complete event had fired.
• 3xx Result – Objects that are highlighted in yellow indicate that 3xx status code has occurred, such as a request or cache request.
• 4xx Result – Objects that are highlighted in red indicate that a 4xx status, or error code has occurred. These should be investigated ASAP.

Checklist Tab

The checklist tab is a report card of how well your site takes advantage of performance related settings and procedures.

• Topics are listed from left to right in order of importance.
• A green check mark indicates a “pass”
• A yellow triangle indicates a “warning”
• A red X indicates a “failure”

The table below provides information on the meaning of each topic, what objects they apply to, as well as what is checked.

The table below is courtesy of WebPageTest.org

Information to solving failures and warnings:

• Failures in the Cache Statics column indicate that the HTTP Expires Web content header is not set.
• Warnings in the Cache Statics column indicate that the HTTP Expires Web content header has a value set to less than 30 days.
• Failures in the Combine CSS /JS column indicate that CSS and or JS files are not combined into fewer files, indicating that multiple requests are being made to pull in these objects.
• Failures in the GZIP text column indicate that static compression is not enabled on the web server.
• Failures in the Keep-Alive column indicate that HTTP keep-alive is not enabled on the web server, causing a connection having to be initiated for every object requested.

Optimization Report Tab

The Optimization Report provides general information related to load times for the page, as well as where improvements can be made (based on the topics in the Checklist Tab). In some cases, such as compression settings, an estimate of how much savings in terms of size will be provided.

The Optimization Report is a textual view of what is presented in both the Waterfall and Checklist tabs.

Load Details Tab

The Load Details view is a detailed account of what happens with every request. This information is useful for narrowing down issues with a particular request.

As always, comments are welcome to help keep Recommended Practices current and dynamic.  Thanks – Dan.

Presentation

• Limit the number of layouts in favor of sublayouts. The aim should be to have one layout per site per device.
• Place components that appear in every single page statically (in the markup) of the layout. Use placeholders to dynamically bind components that only appear in some pages. Group components that are always used together in sublayouts.
• Set presentation details on the _standard values whenever possible.
• Use the FieldRenderer or the other Sitecore presentation controls to enable the PageEditor functionality. You can still use those components for rendering fields that should not be editable setting the disable-web-editing attribute.
• Make sure to use the appropriate image manipulation parameters to ensure that images are re-sized on the server and unnecessarily large files are not sent to the browser.
• Make sure to use the DataSource — by using $sc_item instead of $sc_currentitem in xslts, the DataSource attribute on WebServer controls or with the appropriate code in Subalyouts. This facilitates creating multi-variant tests (MVT) and personalization rules in the OMS.
• Leverage the presentation component parameters. You could use the parameters to allow users to configure/modify the behavior of the component, for example, the number of items shown in a list, the CSS classes to use, the URL for a feed it is showing, and so on.
• Make sure to create a template for any parameters in the presentation component, and set the Parameters Template Property.
• Test components appropriately. For example, a menu rendering might work fine with a few items, but struggle when you have large amounts of data.

Page Editor

• Sitecore recommends that you enable and configure the Page Editor for non-technical users.
• Configure the placeholder settings so that users are able to add the right components to the page. In addition, use the Editable check-box to disable the ability to add components in the Page Editor to a particular placeholder. Also use security (disable Write access) to disable the placeholder for certain users only.
• Use EditFrames to enable editing fields that cannot be edited inline.
• Consider using the Page Editor buttons, and the Datasource Location, and Datasource Template fields in Sitecore 6.4 and later.
• Make sure you test your CSS. It might have an impact the way the PageEditor displays.

Solution Code

• Sitecore highly recommends using C#. All of the Sitecore programming examples are in C# and C# is the language spoken by Sitecore Support.
• Follow best practices for Web, Windows, IIS, ASP.NET, XML, XSL, SQL, .NET, CSS, JavaScript, and other technologies. For example, comment your code to describe the intent, not the implementation.
• Use GUIDs where possible instead of path / name. This will improve performance, as well as prevent any breakage if you move content to a new location in the content tree.
• Use the Sitecore Search API instead of query or fast query. This allows querying based on indexes, rather than the content structure. For more information about search, see Alex Shyba’s blog post http://sitecoreblog.alexshyba.com/2011/02/8-reasons-to-use-new-search-in-sitecore.html and http://sdn.sitecore.net/Reference/Sitecore%206/Sitecore%20Search%20and%20Indexing.aspx
• Avoid //, descendant and descendant-or-self axis in XSL renderings.
• Use App_Config/Include files instead of directly modifying the web.config file.
• Don’t hardcode information in the code, use <settings> in a *.config file.
• Use parameters and properties when creating pipelines/events.
• Don’t hardcode labels and other static text information, consider modeling it with items, or create a dictionary in Sitecore.
• Minimize the use of the SecurityDisabler, and try using SecuritySwitcher when possible.

Media

• We recommended that you store media in the database, rather than the file system. Storing media in the file system instead of the database limits the CMS functionality that is available.

For example, you can easily publish media that is stored in the database to a production target, whereas file system based media requires synchronization of directories and files between servers.

• The folder structure of the media library should be organized so that it is easy to navigate for non-technical users.
• Give media items names that can easily be recognized and understood by business users, such as content authors.
• Media items should be optimized, using a graphics program such as Photoshop to decrease the size of a rendered page thereby increasing performance.
• Image Fields — Define the source field to show the point in the media library that is relevant to the item being created.

Workflow

• Sitecore recommends that you enable workflow. Workflows ensure that items move through a predefined set of states before they become publishable. This ensures that content always receives the appropriate reviews and approval before it is published on the live web site.
• Workflow can be very useful even when approval is not required. A simple two state workflow (Edit, Publish) can be useful to ensure that items that are currently being edited are not published when you run the Publish wizard. In addition, this provides auto-versioning. By using an auto-publish action in the Publish state, users who are not members of the Publishing role can also publish content.
• Apply appropriate workflow security.
• Limit workflow publishing to specific roles and users. In the workflow, provide a default final step with the publish action.
• Avoid email notification of every workflow state. Only provide email notification where it makes sense for a critical workflow event. Alternatively, you can use of the RSS feeds instead of email.
• Try to minimize the number of workflows, states, and the number of actors involved.

Security (Users and Roles)

• Break inheritance rather than explicitly deny access rights. It is a recommended practice to break inheritance in case the access right should be denied instead of explicitly denying it for a security account. If you deny an access right explicitly, it won’t be possible to override the denying access unless you do it directly on a user account. This will create an overhead in security management in case you would like a user to inherit this role and some other one that should allow the right access.

Example:
There is a role A that denies a write access to a “/home/contact us” item. There is a role B that allows write access to the item. There is a user AB that should have power of both roles A and B. But due to explicit deny permission on the item, the user won’t be able to get write access on it. When you break the security inheritance it sets permissions into default deny state, which could be overridden, by setting up explicit allow access on a role. But explicit deny access can never be overridden by explicit allow access.
Refer to:  http://sdn.sitecore.net/upload/sitecore6/security_administrators_cookbook-usletter.pdf section 5.3

• Security applied to roles rather than users. It’s recommended to configure security rights for a role security account rather than a user one. Even if there will be only one user in the system with unique access level, it’s still better to have permissions configured for a role account. It’s much easier to maintain security system which has all the configuration setup on role security accounts
• Limit access to parts of the content tree that are relevant to the user logged into the system.  For example, a person responsible for news items may not have requirements to access the about us page.  This not only allows the user to focus only on what is relevant, but also provides performance benefits by not having to render the entire content tree.
• Limit access to the ribbon items by disabling features that are not relevant to the user logged in.
• No users should have empty or obvious passwords.
• Use the profile setting of the user properties to lock a user to use a certain interface no matter what they select in the login screen.
• Make sure that users belong to only the required Sitecore Client roles.
• Administrator users should only be used to perform administrator tasks (mainly unlocking other user’s items).

Soon, all of the sections that make up the Sitecore Recommended Practices will be available as a document on the SDN (Sitecore Developers Network).

As always, comments are encouraged to help keep this document current and dynamic.

Information Architecture (Content Structure)

• Provide a content structure that closely mimics that of the web site.  This will allow for navigational controls to easily be built, allow for security rules to easily deny or allow access to various parts of the tree, as well as simplify the task of finding any given item within the content structure.
• Limit the number of items under any given node that share the same parent, to 100 items or less for performance and usability.
• Limit the number of versions of any item to the fewest possible.  Sitecore recommends keeping 10 or fewer versions on any item, but policy may dictate this to be a higher number.  There is a shared source module, Version Manager, available at: http://trac.sitecore.net/VersionManager to help manage versions.
• For business users, such as content authors, turn off Standard Fields to improve performance.
• Avoid using the Rich Text Editor to define structure, this is the job of the presentation layer.
• Use the special syntax to restrict the results on Treelists, DropTrees and TreelistEx to make sure users can only select the appropriate items, or Sitecore query in the other selection fields.
• Use TreelistEx instead of Treelist when showing very big trees (like the Home node and descendants) or having lots of Treelist fields in one single item. TreelistEx only computes the tree when clicking “edit” whereas Treelist will compute it every time on render.
• Remember the structure of the tree has an impact on URLs by default. If you put items inside a folder, that folder name will be part of the URL.
• Do not put items that should be accessed by URL (and have presentation details set) outside of the Home of the site, as you will get /Sitecore/content in your URL.
• Remember to set Insert Options appropriately to enforce the topology of the tree by restricting what types of items users can create in the different parts of the tree. This can be further restricted through security.
• Insert options can be tailored further through Rules (/sitecore/system/Settings/Rules/Insert Options) This allows to add/remove insert options according to dynamic conditions (number of existing children), or type of content. This feature is particularly useful to avoid having to create new “Folder templates” to assign the insert options.

I encourage people to comment, so that this series of recommended practices will stay dynamic and current.

Templates and _Standard Values

• Naming conventions – When naming templates, fields, and sections use simple, relevant, and easy to understand names.  By default, Sitecore displays the names you provided to both technical and non-technical users.  Choose names that business users, such as content authors, will easily recognize and understand. Folder structure – Provide a folder structure to classify by web site, site section, section content, function, etc.  This will make for easier navigation and finding of a given template.
• Good use of inheritance – Commonly used sections and fields should be placed in their own template, so that more specific templates can inherit them.  For example, the fields page title and page text are used in multiple different content templates.  Rather than duplicate theses fields in each content template, simply inherit the page title and text template.
• Avoid duplicating field names.  Even though sections separate fields, do not reuse a field name within the same template. Be careful of not have two fields with the same name in the inheritance chain either. If you really need two fields with the same apparent name in the Content Editor in different sections, use the Title field of the field definition item. Whenever this field is set it is used by the Content Editor instead of the name.
• Assign icons to templates – Provides a visual clue to the type of item that will be created.
• _Standard Values – Define layout details, initial workflow, and insert options to a template.  This will reduce administration and centrally manage system settings, rather than setting them on individual items.
• _Standard Values – Provide default values using tokens that are meaningful and provided clues to business users, such as content authors, as to what information is expected in a given field.
• _Standard Values – Use tokens, such as $name, to reduce the amount of text that a content author is required to enter when creating a new item.
• Image Fields – Define the source field to show the point in the media library that is relevant to the item being created.
• Rich Text Editor Fields – Set the source property to a profile (found in the core database under /sitecore/system/Settings/Html Editor Profiles) that only shows the controls you want to make available to your business users.
• Do not override, or delete any templates located under /Sitecore/Templates/System.
• Use the Help option in the individual field definition items to provide extra information to users about fields. Also consider using the “Title” field of the definition item to present to the user a different name for the field.
• Remember that the name of your templates will appear as the insert options. Try to use something meaningful to the users. Use the Display Name to provide a different text to the user to the name of the template.

By setting Expire Web content to something  other than immediately, you can reduce second-access load times by 50 to 70 percent.  This setting will not affect dynamically generated content.

To enable the Expire Web content header (note: this is based on IIS 7.x):

1. Launch IIS Manager.
2. Navigate to the site that you wish to enable the Expire Web content header.
3. Double click on the HTTP Response Headers (located in the IIS grouping).
4. In the Actions panel, click on Set common headers…
5. Make sure that the Expire Web content is checked.
6. Make sure that After is selected.
7. Keep the number of days at its default (7).
8. Click OK when finished.