Sitecore Performance. Technical Deep Dive. Steve Green, Solution Architect

Transcription

1 Sitecore Performance Technical Deep Dive Steve Green, Solution Architect

2 Webinar Agenda Technical Introduction Divide and conquer Starting on a solid footing General improvements Sitecore specific improvements Content Entry Next steps...

3 Just a few notes 1. We will have time for questions at the end of the presentation. 2. The webinar will be recorded and the slides will be available for all to use. 3. Feel free to me questions about the presentation ([email protected]) 4. Code examples used throughout the demo will be made available for public use. 5. Like the name suggests, we are in a Technical Deep Dive. Some basic understanding of Sitecore and ASP.Net is necessary to get full understanding of all the concepts being presented.

4 Technical Introduction Sitecore is designed to drive the largest sites on the planet Powers incredibly high load sites such as: Over 25,000 web sites in 50 countries In terms of licence sales alone Sitecore is in the top 3 CMS in the world.

5 Technical Introduction What won t be covered? In order to keep the webinar to a reasonable size I ve avoided going into any great detail on: Caching Debugging Logging and monitoring Development Best Practices Also keep in mind that the topic of improving website performance is huge; consider this webinar a primer.

6 Technical Introduction Disclaimer: Speed isn t everything! When asked speed is rarely the #1 concern customers have. Instead they want: Bug free code Features Ease of use Speed comes after these considerations, nobody wants code that doesn t work no matter how fast it runs. With this in mind your goal should be to reduce complexity, speed is a secondary objective.

7 Technical Introduction No such thing as a one size fits all. Each project needs to clearly define the required: response time acceptable throughput per server simultaneous sessions maximum supportable traffic

8 Divide and Conquer Break the problem down into parts. First step is to split the system into content entry and content delivery. Simplifies the problem greatly. Licence considerations but out of box ROI would be greater than additional coding or hardware. Possible to continue without it but I will be working on that basis.

9 Divide and Conquer Try to break complex pages down into their constitute components. If you have any webservices, 3rd party applications or any other tightly coupled systems integrated into the site then find ways to have them temporarily turned off while you test the website. Ideally you can isolate the various components and test each independently of the other.

10 Starting on a Solid Footing When trying to improve website performance the worst sentence you can hear is it feels slow. Replace gut feelings about speed with objective facts. Once you are on a firm footing as to how fast it performs now agree upon how fast it should perform in future. Each site is different, the Google homepage will always load faster than the Amazon homepage.

11 Starting on a Solid Footing How do we obtain solid data on the speed of our site? Jmeter - Yslow - Standard.Net techniques ANTS profiler - Sitecore Debug Mode

12 Starting on a Solid Footing JMeter is a free stress testing/monitoring tool. With it you can measure site throughput in pages per second and overall response time in milliseconds. Recommend running JMeter during development to ensure performance issues don t sneak in.

13 Starting on a Solid Footing Firebug -

14 Starting on a Solid Footing When judging the performance of code a great technique is simply timing how long blocks of code take to execute. You could do this by comparing DateTime values. DateTime is very precise, 10 million ticks per second, but it is wildly inaccurate. Despite all that precision you will find it stays on the same value for a relatively long period of time and then jumps forward. It is only accurate to 1 millisecond. StopWatch on the other hand is made for this purpose and while less precise is far more accurate.

15 Starting on a Solid Footing Ants profiler -

16 Starting on a Solid Footing Sitecore Debug Mode

17 Starting on a Solid Footing Sitecore Cache Statistics

18 Starting on a Solid Footing Sitecore Rendering Statistics -

19 Starting on a Solid Footing First step is to log all of this information in a spreadsheet. Then as you complete each suggested improvement take another measurement. This will allow you to carefully track improvements and separate changes that work from changes that don t. If a modification makes no improvement then remove it.

20 General Improvements General improvements not specific to Sitecore Frontend HTML/CSS Improvements IIS Configuration

21 General Improvements YSlow has a number of recommendations it makes on how to reduce page weight and response time Aim for an A rating but not slavishly Some recommendations such as using a CDN will have a dramatic effect on performance but may cost money to implement. Google offers free CDN support for the jquery libraries.

22 General Improvements Try to avoid unnecessary HTTP requests where possible as each one has an associated overhead. Remove unused CSS statements using CSSusage addon for Firefox -

23 General Improvements Minify your JS and CSS files, this will remove all unnecessary whitespace characters which will make the files largely unreadable but often much smaller without affecting how they behave. CSS Sprites - = +

24 General Improvements Generally speaking you want to reduce the overall page weight. Easiest way is to move as much presentation logic (tables) out of the HTML and into the CSS. Viewstate is likely only needed on pages with forms, otherwise disable -

25 General Improvements JustAgile.com has an excellent article on.net tuning on 64 bit systems. - Key Point: Always set <compilation debug= false"> in production. This gives you 3 benefits: ASP.NET Timeouts Code will timeout rather than lock up resources. Batch compilation Compilation of ASPX and ASCX in batches rather than individually. Code optimization Assemblies compiled with performance rather than debugging in mind. Take care making changes, not everything in this article will be suitable for your site.

26 General Improvements Enable compression in IIS Exchanges Bandwidth for CPU Excellent article on Scott Forsyth s blog:

27 General Improvements When developing in Sitecore or.net in general you often get a delay after resetting the app pool. Typically this will happen because you ve just recompiled but changing the web.config or other sensitive files can trigger a reset. Some of this delay can be attributed to Sitecore startup process, prefetching items from the database etc but much of it is general to.net. Alex Shyba has an article about how to reduce this delay, dramatically so when the computer lacks a network connection:

28 General Improvements There are some obvious steps you can take to improve performance that I won t go into in detail: Upgrade software, IIS7, SQL2008 etc. plus Service Packs Switch to x64 systems, I ve seen an increase in performance on x64 over x32. Increase number of Content Delivery Servers. Check performance of load balancer, routers, bandwidth. Create dedicated database server/cluster for Sitecore. Vertical and Horizontal scaling can solve any and all performance issues; for the right price.

29 General Improvements Have seen issues with virtual machines with low hardware contention. Some companies are selling virtual quad-core servers that don t perform even remotely the same as a real quad-core server. Also seen issues with low network hardware contention. On high demand sites I ve seen packets dropping as the physical network card refuses to process the network traffic fast enough because the VM hasn t been given high enough priority.

30 Sitecore Specific Improvements Improvements specific to Sitecore Caching Custom Lucene Indexes Control Performance FastQuery PathCache XSLT vs Webcontrol vs Sublayout Avoiding queries Link Database Config Changes Information Architecture

31 Sitecore Specific Improvements Cache is a multiplier Site should be able to run without it Don t use it to cover up poorly performing controls. When load testing during development test against an uncached site, this way you can spot performance issues before they occur. Refer to caching webinar by Tim Ward

32 Sitecore Specific Improvements Word of warning regarding abstraction layers. The first thing a lot of people leap to when they first start using Sitecore is generating an additional abstraction layer on top of Sitecore. Typically these allow the developers to write code such as: Article article = (Article)abstraction.getObject(Sitecore.Context.Item); String alttext = article.author.portrait.alttext However! I have seen this cause massive performance issues that wipe out any gains made during development. In the case above if lazy loading isn t implemented then article.name would still load the Author item etc. I advise caution before implementing one of the existing abstraction layers and extreme caution before writing your own.

33 Sitecore Specific Improvements Review the cache and stats tools Cache: /sitecore/admin/cache.aspx Stats: /sitecore/admin/stats.aspx Debug mode will also give you an ASP.NET Trace style breakdown. When you re running in debug mode it has turned caching off.

34 Sitecore Specific Improvements If you re working with taxonomy systems, tag clouds or any kind of item relations that go beyond simple child/parent then consider creating a custom lucene index. Resources: n/lucene%20search/lucene_search_engine.pdf

35 Sitecore Specific Improvements Sitecore Fast Query is designed for retrieving and filtering items from the Sitecore database. Fast Query uses the database engine to execute queries. Improved performance queries are executed by the SQL engine. Consumes less memory Sitecore Query loads every item that it touches into memory (cache), Fast Query only loads the items from the result set. The trade off is that Fast Query only supports a subset of the normal query system: Limited axes and attributes support Standard values not supported Functions, Operators and SubQueries not supported Only returns items from the SqlDataProvider

36 Sitecore Specific Improvements All Sitecore item paths (/sitecore/content/home) are mapped to a particular GUID which is then used to retrieve the item. These mappings are cached in the Path cache which can in some situations be used to increase performance. Refer to the caching webinar.

37 Sitecore Specific Improvements XSLT vs Webcontrol vs Sublayout In terms of absolute performance difference they don t vary greatly. Wrong tool at the wrong time is biggest cause of performance issues. Decision should be made based on which one reduces overall complexity. Don t limit yourself to just sublayouts, learning how to create XSLT renderings and webcontrols will speed up development greatly.

38 Sitecore Specific Improvements XSLT offers simplicity and rapid development Often you can start with XSLT in mind and if there is any sign of it becoming complex switch to webcontrol or sublayout. Only create XSLT extensions if doing so would simplify the controls. Keep in mind that XSLT can t create forms or sitecore placeholders.

39 Sitecore Specific Improvements XSLT Performance is mainly affected negatively by two things. Misuse of descendant traversal. Keep in mind when developing how large the content tree could become once the site goes live. Extension methods. There is an overhead associated with using extension methods but performance problems typically arise from problems in the method itself.

40 Sitecore Specific Improvements The default XSLT file can be modified and existing ones can be trimmed. \Website\sitecore\shell\Templates\xsl.xslt Remove unused variables, like $home Remove unused references The dot extension method is now depreciated and can be removed.

41 Sitecore Specific Improvements Avoid using queries when the item required can be handed to control. Datasource Parameter template Link field on context item Static helper class can contain Guids to commonly used items/templates. For SubLayouts try:

42 Sitecore Specific Improvements Webcontrols are used when you would otherwise be using a literal controls to output HTML. Typically easier to create than asp:repeater. Especially when the output is something more complex that a simple iteration through multiple items. Obvious downside been the lack of separation between code and presentation that usercontrols have.

43 Sitecore Specific Improvements Templated controls represent a halfway house between the flexibility of a webcontrol and the separation of code and presentation that a usercontrol provides. Easiest way to think of them is as a bespoke datalist control. Can be complex to create but should be reusable.

44 Sitecore Specific Improvements Guids vs Paths, human readability vs performance. Only use paths when you re referencing a position in the content tree rather than a particular item. Typically this is very rare. Avoid queries and recursion method to find things like the site root item or settings items. Use a guid helper class instead.

45 Sitecore Specific Improvements UserControls (SubLayouts) will be the control most people are familiar with. They provide a neat separation of presentation and content. Typically their main purpose is to generate placeholders and forms. Switching from CodeBehind to CodeFile will allow you to make changes without needing recompile.

46 Sitecore Specific Improvements Don t limit yourself to just content tree traversal. Sitecore tracks all item relationships in the link database allowing for many to many relations. For example article items linking to author items, the link database can provide a list of all articles belonging to a particular author. Likewise you can request all items of a particular template the same way.

47 Sitecore Specific Improvements Number of performance improvements can be made with the caching configuration, refer to the caching webinar. If your Sitecore server is only hosting a single site you can disable the site resolving feature of the LinkManager: <setting name="rendering.siteresolving" value= false"/>

48 Sitecore Specific Improvements The Information Architecture of a site can have a huge impact on its performance. Sitecore itself has no hard limit on the number of items or the depth of the content tree however many browsers struggle with the time taken downloading the details of items with 100+ children. I would recommend 12 wide, 5 deep as a rule of thumb. No more than 12 child items and no deeper than 5 levels. This gives you around 270k items, if your site was vastly more than this I would recommend a taxonomy system. You can enforce the depth limit in the Web.config with the maxtreedepth setting

49 Sitecore Specific Improvements A taxonomy system can take many forms but in essence it is where content is stored in a separate section to the website structure The renderings pull information from content repository based on search criteria specified on the category nodes or simply by selecting the items in a treelistex field. I recently wrote a module with taxonomy systems in mind which allows items to appear in multiple locations based on the selection of a treelistex field:

50 Sitecore Specific Improvements When creating fields for your items only store information that is unique to that item. Information that is used throughout the site should be stored on settings items stored in a separate global folder. Avoid storing this information under the site root as it is unlikely to have presentation information and can be mistake for a valid page. Don t create generic key/value templates to store content, there is no cost associated with creating new templates, even when that template will only be used once (i.e. /sitecore/content/global/settings/breadcrumbsettings)

51 Content Entry The easiest and quickest way to improve the speed on the Sitecore UI is to follow the IE configuration guide. uration%20reference.aspx Typically 99% of all speed issues are resolved after following this guide. Often this configuration can be pushed out to all machines on the network by the companies IT team.

52 Content Entry In terms of custom additions that can cause performance problems in the UI there are 2 key culprits, custom validations and workflow actions. Each can be potentially resource hungry depending on the action been undertaken. Often the speed problems can be down to a resource lock of some form that only occurs when multiple content authors are working on the system. Beyond any obvious performance issues like descendant traversals the easiest solution is to detect whether or not the action is required early and to return early.

53 Content Entry Some performance gains can be made by reducing the page weight of the UI. This can be achieved by switching to the limited content editor role which has vastly reduced number of commands and UI options. You can create your own custom version of this by inheriting from the limited content editor role and adding/removing commands as needed by granting the appropriate permissions on the core database.

54 Content Entry Login to just the content editor or other application directly as required instead of the desktop. Because of the reduced page weight some fields such as TreelistEx will load faster.

55 Content Entry Sitecore is by default geared towards high bandwidth, local connections; changing the below settings will gear towards low bandwidth, remote connections but at the detriment to the former. Switch off field section prefetching: Switch off security check in UI for content tree: <setting name="contenteditor.checksecurityontreenodes" value="false"/> Switch off child item check for content tree: <setting name="contenteditor.checkhaschildrenontreenodes" value="false"/>

56 Content Entry Another 2 options for remote/low bandwidth connections are: Use Chrome, whilst not fully supported and does have some issue with file uploading among other things it can perform very quickly under these conditions. Use Page Editor, inline editing can in many situations be a faster way to make changes on the site for remote users.

57 Parting Words Caching is a multiplier. Develop with caching switched off, treat poor performing controls as bugs. <setting name="caching.enabled" value= false"/> Scope the addition and testing of caching into the end of the project.

58 Parting Words Continuous integration. Agree in project plan on acceptable response times. Ensure you meet them throughout development. Stress test throughout the project. Script the automatic creation of dummy items to simulate the expected site size at launch.

59 Learning More Training Developer Course Documentation on SDN Cache Reference Guide Caching webinar by Tim Ward Presentation Component Cookbook Presentation Component Reference

60 Learning More MSDN Resources Performance Checklist Article on improving performance

61 Learning More Other Subscribe to the Sitecore Blog RSS feed Code Complete 2 nd Edition by Steve McConnell

62 Questions? Asking a Question Please state your name and where you are from Please be aware that specific questions to your own implementations can be answered in . The questions should be directed at global answers that all can benefit from. Some questions may need to be answered with more investigation.

63 The End Please send all requests, questions and ideas to Sign up for the AUS/NZ Developer Mailing list by ing myself. My blog is available at Presentation will be available on request or via my blog and the Sitecore Australia blog.