Just make sure to replace the field name strings with a reference to a GUID class and you will be all set!
Saturday, July 18, 2009
Friday, July 17, 2009
Applies to 5.3.x and 6.0.x.
Recently discovered issue with disabled “registry” cache can potentially increase chattiness of your Sitecore web server with SQL Server.
Basically what happens is regular SQL selects from ‘Properties’ table that stores user-based registry settings for a current site. The call is initiated by Item.DisplayName property which is frequently used on the delivery boxes too. This is not a problem for the authoring environments that operate in the context of “shell” site by default since the registry cache is enabled there. This is not the case for “website”*** as two places where this may be changed contain zeros:
<site name="website" … registryCacheSize="0" … />
The way to fix this is to simply adjust the value of registry cache. You can try 1KB and monitor the /sitecore/admin/cache.aspx page to see the actual consumption. From my experience, it is rarely even approaching 1KB in most installations unless you are writing something there with custom code.
This will be officially documented as a known issue and published on SDN.
In meantime, go ahead and put it in your web.config ;-)
*** If you have a multisite environment, change this on the level of your custom site definition responsible for the front-end requests. If in doubt, let me know.
There seem to be a lot of confusion on the forums on this topic, so the doc team updated the article about why the warnings are commonly appearing in live environments even when the code is optimized.
The basic idea is that the functionality was not designed for usage under load tests or in production, so the best way would be to simply disable this functionality in production systems. Otherwise, your log files will be just filled with warnings and it will make difficult reading them.
To disable, simply remove the StartMeasurements processor from the “httpRequestBegin” pipeline and “StopMeasurements” from “httpRequestEnd”.
I suggest you do use the thresholds in QA when running tests, just make sure you have a single request test to identify the problematic pages.
Same rules apply to media requests that report threshold violations. If this happens under a single user load, make sure you don’t have a crazy number of items in the requested branch. I’ve seen media libraries when that was the case.
Take it easy.