Most of us being developers continue to love working on Sitecore because of its scalability, extensibility, high flexibility and modular features which at a given point of time can be overridden by developers to match implementation or business needs.
With such extensibility and flexibility, it comes on to developer’s responsibility for using sitecore with a lot of caution. That’s what we have heard many times from a friendly neighborhood guy, “With great power comes great responsibility”
We recently launched a full fledge sitecore commerce implementation site for one of our customers. In order to button up ourselves making sure site is performing optimally and we do not run into performance issues after going live. We had planned stories and implementations tasks to make sure we look closely to increase sitecore site performance.
Even after making necessary changes, setting and configurations for performance in place after going live we observed site was crashing and server memory occupied by W3WP worker process was continuously remaining high. Sitecore setup was a scaled deployment with two Content Delivery servers and either of the CD servers sitecore site will crash once it reaches 100% memory utilization.
While troubleshooting we discovered one of a setting in sitecore
<setting name=”Caching.DisableCacheSizeLimits” set:value=”true”/>
was set to true
Documentation at sitecore “Disable the cache size limit” did mentioned a warning
which was now obvious that one of our developer completely ignored it and enabled this setting.
As it was an xml patch config file removing the patched setting was straight forward for us to resolve the site crashing problem.
Once this setting was set to value false server memory was well contained to a limit of 60% utilization and no frequent site restarts were observed.
Sharing a finding / setting that needs to be used cautiously as for gaining performance you hit a site restart is not an intellectual move.