Sitecore Best Practice Series:
|1.||Adjust Sitecore topology based on resource usage||For Sitecore to perform, not only it needs to have the adequate amount of resources, but also proper horizontal scaling. A topology that doesn't fit the usage can either hinder the platform's performance or result in excess cost and wasted resources. Check your resource usage periodically, about every six months for topology optimization opportunities.|
|2.||Style the Sitecore environment||Sitecore allows to customize the login screen background, styling and the information displayed. Same goes for the Launchpad and Desktop. Give Sitecore client tool some style and configure it to align with your companies branding for improved experience.|
|3.||Configure default login environments for users||Sitecore allows configure default user login environments. Save your users a few clicks and log them directly into the environment that they work in most frequently.|
|4.||Periodically tune Sitecore caches||Sitecore provides several layers of caching and with time they need to be adjusted to make sure the platform continues to operate optimally. Check and tune Sitecore caches at least once a quarter using the Cache Tuner module.|
|5.||Keep the number of item version below 10||This practice helps improve Content Editor performance. Sitecore PowerShell can help run a periodic report and remove the old versions.|
|6.||Implement a logging management strategy||Sitecore automatically generates log files, however, it doesn't delete them. This is a concern of Sys Admins, thus, as Sitecore Admins we need to remember to implement proper logging and archival strategy to control the number of logs that get generated and stored for future reference.|
|7.||Archive media items periodically||Sitecore Media Library can quickly get out of hand, especially when assets get uploaded and updated frequently. Perform periodic cleanup using Sitecore PowerShell by archiving the unsued assets. This practice help improve the usability of the Media Library and keep the cost of the master database in check.|
|8.||Modify log4net file naming format to display dates first||Sitecore Desktop Log Viewer sorts files by name by default and does not provide sorting functionality. When putting the data first, files get sorted in the order they are updated, making easier to find the most recent logs. Check out John West’s article on Cleaning up Logging Clutter.|
|9.||Disable Sitecore performance counters on CD servers||Sitecore performance counters add processing overhead to the Sitecore instance, thus, they should only be used for debugging purposes.|
|10.||Enable IIS static and dynamic asset compression||This practice helps increase page load speed.|
|11.||Set the compilation node’s debug attribute to false||Helps improve application performance (MSDN Article on the compilation debug setting).|
|12.||Use Solr to power Sitecore for all implementations||Lucene has been deprecated and Azure Search is deprecated with 10.2. Here is a guide to setting up Solr in production.|
|13.||Use scheduled publishing||Sitecore clears the caches for when items under the sites in configuration get published publish; frequent publish operations will dramatically slow down the website performance.|
|14.||Regularly clean up and rebuild link databases||This practice helps increase Sitecore's performance and eliminate errors during data access.|
|15.||Configure automatic unlock on item save||This practice helps mitigate issues with editors leaving locked items and making them inaccessible for other users.|
|16.||Harden CD servers||This practice helps increase security of the CD environment. Check out the Sitecore Security Hardening Guide.|
|17.||Setup Continuous Integration & Continuous Delivery||There are numerous benefits of implementing a Continuous Integration (CI) and Continuous Delivery (CD) pipeline from cost savings to improved quality and security.|
|18.||Evaluate the need for a Preview environment||It is possible to set up a separate Preview environment, an internal replica of a CD with its own publishing target. This would allow internal users preview changes before the go live without having a Sitecore account (license restriction for instance), however, this environment is not supported by publishing restrictions out of the box, which may cause issues down the road with content governance.|
|19.||Disable the Publish button||Site-wide publishing may result in accidental publishing of additional content. In addition, content editors tend to prematurely publish content updates, resulting in a large number of publishes, which in turn negatively affects website performance. Use scheduled publishing and only give access to manual publishing to select content leads for urgent publishing.|
|20.||Use a dash for the media URL instead of a tilde||The IIS applies special security evaluation rules to URLs containing a tilde.|
|21.||Configure Sitecore to replace spaces with dashes in item names||Item names are used for URLs, “item-name” is much more readable than “item%20name”, plus it improves the SEO of the website.|
|22.||Set log4net to only record errors||Log4net will not use as many resources when it is only set to record errors.|
|23.||Restrict access to the client editing tools in CD environment||Leaving Sitecore client tools available may present a security risk.|
|24.||Remove the “master” database in CD environments||In a scaled environment with separate CM and CD servers, the “master” database on the latter is not used; leaving the database accessible may lead to security risks and unnecessary usage of resources. CDs should never write to the "master" database; if the solution does so, it should be refactored to avoid security risk.|
|25.||Disable Sitecore Upload Watcher||The Upload Watcher automatically creates items in the Media section for files in /Website/upload folder, which may present a security risk when it's left exposed.|
|26.||Enable sticky sessions in load-balanced environments||Although some may argue that server affinity slows down requests, lack of it will result in other solutions that generally create additional overhead, which does not outweigh the gains in performance.|
|27.||Use Sitecore Dictionaries||Dictionaries allow making miscellaneous web page copy like labels multilingual, versioned, and editable in Experience Editor.|
@vasiliyfomichev:disqus Thanks for input, If I want to scale out and add one more CM server for redundancy without load balancing, as you suggested how to go for failover with minimal changes in existing architecture any blogs suggesting how to do add a failover CM server can you suggest.
Thanks for quick reply @Vasiliy Fomichev.
As single CM is performing slow , instead of failover can I go for a separate publishing server to take care of publishing task and keep load off from my CM.Or should I look for any other changes to improve performance?
Hi @faiyazulhaquenoor:disqus , a single Sitecore CM instance should comfortably handle that. Scaling on CMs is usually done fore redundancy, not that Sitecore can’t handle the amount of authors. CM scaling can also get tricky with sessions, agents, processing…etc. so I usually recommend having a cold failover instead, if possible.
Any suggestion on number of CM servers one should have for around 50 content authors?