• Define backup strategy (SQL, file system, disaster restore / recovery plan).
• Perform SQL maintenance (shrink transaction log, rebuild indexes).
• Plan outages and take necessary steps to notify the appropriate people.

• Review and address performance issues.
• Keep software patched and up-to-date including Kentico, the operating system, SQL server, etc. 
  • Decide whether to upgrade or not.

• Archive old data.
• Remove unnecessary objects (e.g., old content versions, unused media files, inactive contacts, old web analytics, staging tasks, unsent emails, old online marketing activities, etc.).
• Update and optimize content (e.g., update outdated content, fix broken links, perform AB tests, etc.).
• Deploy new content and changes from staging to production.

For additional information about maintenance in Kentico please refer to the Maintenance in Kentico article.

Diagnosing performance issue caused by a large amount of content

A client runs a large news web site with hundreds of thousands of articles in the content tree. Over the time the web site performance rapidly went down.

When the client checked the SQL server resources, they realized that the usage had increased significantly. Further investigation with SQL Profiler revealed that the issue is caused by having more than 1,000 pages under a single parent page, which is against the best practices.

To prevent this from happening again, the customer created a custom report in the Reporting application that automatically sends an email notification once per week reporting the status of the content tree. Next, they implemented a new business rule that automatically adjusted and organized the content tree structure to comply with the best practices.

Diagnosing website outages

A client was experiencing occasional web site outages that they did not notice until their users started complaining how slow and unresponsive the web site was.

After digging into the event logs, they discovered a pattern where after a content change event, the web site would restart. Whenever an ASP.NET web site is restarted, an extensive compilation might happen. Also, caches have to be primed, which leads to slower page loads after the restart.

The client decided to precompile their web site. This helped a bit with the compilation slowdown, but did not address the underlying issue. They eventually decided to add third party monitoring software to get more information.

This lead them to discover that the web site was restarted due to a change in App_Data folder where Kentico stores smart search indexes, web analytics logs, etc. They knew that this should not happen with .NET and eventually it turned out to be a bug in ASP.NET. They found out that this bug was fixed in a Windows update hotfix.

If the client was monitoring the site and keeping the system up-to-date, they could have avoided these issues entirely.

Large database causing performance issues

A client was utilizing nearly all of Kentico's features including online marketing tracking, web analytics, version history for objects and pages, workflow, and many others.

Since they did not have any data monitoring or a maintenance strategy, the size of the database was growing rapidly (100+GB) and started slowing down the system. Eventually, the added load exceeded the capabilities of their environment and the site went down.

In this case, The web site was a large web site with hundreds of thousands of pages in the content tree, each with an average of 100 versions, and over 100 million contacts, activities, and web analytics entries.

Once they got hte data cleaned up, they implemented a plan to monitor the database size and manage data growth using built-in features like deleting inactive contacts, limiting the version history, and clearing web analytics data on a regular bases.