Sitecore CMS Blog by Alex Shyba: July 2009

Saturday, July 18, 2009

Ways to check field type in code

As a “safe check” code operation in Sitecore, you frequently check for expected field type before working with a field.

While there is an easy way to do it via “Type” property of a field returning string, it may not look really nice and considered hard-coding:

if (Sitecore.Context.Item.Fields["featured"].Type == "Droplink")

Plus backwards compatibility of such code is questionable.

I suggest you use the Sitecore.Data.Fields.FieldTypeManager class that has “GetField” method where you can pass the instance of your field and use “IS” keyword to check if it is safe to cast:

if (FieldTypeManager.GetField(Sitecore.Context.Item.Fields["title"]) is TextField)

if (FieldTypeManager.GetField(Sitecore.Context.Item.Fields["text"]) is HtmlField)

if (FieldTypeManager.GetField(Sitecore.Context.Item.Fields["featured"]) is LookupField)

if (FieldTypeManager.GetField(Sitecore.Context.Item.Fields["metakeywords"]) is MultilistField)

Just make sure to replace the field name strings with a reference to a GUID class and you will be all set!

Friday, July 17, 2009

Registry Cache for “website”

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" … />

<cacheSizes>
<sites>
    <website>
     <html>10MB</html>
     <registry>0</registry>
     <viewState>0</viewState>
      <xsl>5MB</xsl>
    </website>
   </sites>
</cacheSizes>

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.

Item, Memory and Timing Thresholds Demystified

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.

Pages

Saturday, July 18, 2009

Ways to check field type in code

Friday, July 17, 2009

Registry Cache for “website”

Item, Memory and Timing Thresholds Demystified