Presentation is loading. Please wait.

Presentation is loading. Please wait.

Sitefinity Performance and Architecture

Similar presentations


Presentation on theme: "Sitefinity Performance and Architecture"— Presentation transcript:

1 Sitefinity Performance and Architecture
Christopher Peck, Sales Engineer June 4, 2015

2 Overview Performance and Monitoring Deployment Architecture
Development Considerations Client Side Server Side Tools Page Pre-Compilation Diagnostics Module Useful Customizations and Practices Custom Trace Listeners Web Test Runner Deployment Architecture System Requirements Common Setup Scenarios Deployment

3 Development Considerations
Client Side Cache results from jQuery Selectors Server Side Use paging and filtering Use LINQ deferred Execution (Most of the time.)

4 Cache results from jQuery Selectors
Selecting an element with jQuery traverses the DOM tree DOM traversal can be expensive If we use an selector more than once it should be cached. var highlightedItems = $(li.highlighted); highlightedItems.click( function () { highlightedItems.removeClass("highlighted"); highlightedItems.addClass("otherClass"); });

5 Use Paging and Filtering
The API supports paging and filtering. App.WorkWith().NewsItems().Get().Skip(40).Take(20); Use these options to cut down on data loaded into memory and limit load on the connection to the database

6 Use LINQ deferred Execution (Most of the time.)
The API returns IQueryables so we can shift processing to the database server and use deferred execution. Use of ToList() will force the query to execute. This often results in getting too much data from the database and using too much memory on our web server. (Caveat: Sometimes we need to force a query to save an N+1 query later.)

7 Tools Page Pre-Compilation Diagnostics Module
Helps pages load faster when requested for the first time Reduces processor load Skips the warm-up phase when a site is deployed. Diagnostics Module Operation Run Times N+1 Query Problems Custom Reports

8 Demo Diagnostics Module

9 Diagnostics Module Operation Run Times N+1 Query Problems
See services used, the database calls they are making, and duration N+1 Query Problems Tool highlights potential N+1 Queries Lazy loading is great, but be aware of when we need to force prefetching. Try projection strategies to denormalize and preload. Custom Reports RunBigResultSetAnalysis See operations that fetched a significant amount of records RunLongQueryAnalysis See operations that took a long time to run

10 Useful Customizations from the SDK
Custom Trace Listeners Log errors to external systems (e.g. Raygun.io) Web Test Runner Run Integration Tests with Sitefinity.

11 Demo Trace Listener and Web Test Runner

12 Basic Architecture Diagram (Single Level)
Notes: A simple diagram of the simplest setup commonly seen in a production environment. Two servers: one web and one database

13 Simplified Architecture Diagram
Notes: Common architecture with databases removed for clarity. Staging and Development may share a database server. Generally production should have a completely separate database server.

14 Content Flow Detail A content author creates content in staging which is stored in the staging database. On site sync, data is pulled from the database and transferred to the production server which in turn stores the content in the production database.

15 Code Flow Deployment Strategy

16 Code Deployment Source Control Automated Deployment git
TFS and Visual Studio Online Automated Deployment Visual Studio Online TeamCity Octopus Deploy

17 Site Synchronization Fluent API
Using Statement using Telerik.Sitefinity.SiteSync; Facade App.WorkWith().SiteSync() Select Target Server .SelectTarget(" Select Target Sites (Multisite) .SetSites("site1", "site2", ...) Sync a content types .Sync(typeof(NewsItem).FullName, ...) Sync a specific content item for a specific language .Sync(newsItem, CultureInfo.CurrentCulture) Schedule the sync for later (Cron format) .ScheduleSync(“ * 2015”, typeof(NewsItem).FullName, …)

18 Production – Infrastructure Diagram 1(Simple w/ HW LB)
Notes: Common On Premise Simplified Setup

19 Production – Infrastructure Diagram 2(Simple w/ SW LB)
Notes: Common in On Premise or In Cloud Would be suitable for Both AWS and Azure

20 Production – Infrastructure Diagram 3(Simple w/ Azure)
Notes: When using Sitefinity on Azure Cloud Services in a load-balanced scenario (including Auto Scaling) you do not need to configure Sitefinity for Load Balancing. Sitefinity uses the Windows Azure API  to automatically identify the web role instances that must be messaged to invalidate the cache dependencies.

21 Advantages of Azure Database: SQL Azure
Built in point in time and various levels of geo- restore in case of geographic outages Web Servers: Azure Cloud Services Automatic use of Azure load balancing is built into Sitefinity

22 Load Balancing Support both hardware and software load balancing
If running in non-Azure environment load balancing addon must be configured on each web server. Load Balancing addon invalidates caches on updates to content.

23 Staging and Development Suggestions
If using a hosting service the UAT/Staging environment should use the same hosting provider to mirror production as closely as possible It is common to see Staging and Dev share a database server (Different databases/schemas) for cost reasons. We also generally see Dev as a code testing area only with content being added on Staging. Occasionally see 4 tier deployments with QA coming after Staging.

24 Project Assessment Services
We can help you optimize the stability, performance and user experience of your Sitefinity project: We’ll validate your technical solution design Our developers will profile a copy of your project We’ll analyze its code for any deviations from best practices You will get a list of recommendations that will help you introduce optimizations and deliver the project successfully Project Assessment If your Sitefinity implementation isn’t delivering against expectations we can help you optimize and improve the stability and performance of your project and deliver it successfully. How it works? Our developers will profile a copy of your project and will analyze its code for any deviations from best practices aiming to build a list of recommendations to optimize performance, stability and user experience We will provide a report of our findings, which will include technical issues discovered during the review. The report will incorporate documentation on how to resolve the issues. If resolution is impossible, Telerik may provide potential workarounds. Project deliverables may also include software artifacts, such as configuration files or code, which include fixes for technical issues. Telerik will also conduct an online presentation of its finding and present it to stakeholders Why should I use it? If your timeline is tight and the same time the expectations for the project are high, we can help you deliver. The issues teams struggle with vary a lot - this may be vary from unpleasant user experience to issues like slow performance and even stability issues that lead to downtime. In such situations, you need a timely and reliable way to identify the cause for the issues and eliminate it and protect the success of the project and we are there to use our insider knowledge of Sitefinity and give you the answers you need What’s the average engagement in terms of professional service hours? Project audits may have different goals and projects are also different, resulting in broad range of possible hours to complete an audit. A typical audit might take between 20 to 80 hours

25

26 Links: System Requirements Hardware Recommendations
Hardware Recommendations Sitefinity and Azure Site Synchronization Load Balancing Azure SQL Disaster Recovery


Download ppt "Sitefinity Performance and Architecture"

Similar presentations


Ads by Google