Following on from an earlier article I wrote (XslLink Property and XsltListViewWebParts), I've continued to see intermittent performance issues
with XsltListViewWebParts where custom Xsl has been implemented - both in remote files or added as an inline property to a page. The performance problem surfaces in the UI as a
correlation ID on a List View Web Part which, when the page is refreshed, works fine. Most often the error occurs following an IISRESET or the deployment of a solution package. When interrogating the SharePoint ULS logs to investigate, the log files reveal
problems with the Xslt Transform process going on behind the scenes.
While investigating yet another occurrence of the same problem recently, the error showed up in the logs as a Stack Overflow error. As usual, I started to search the internet for any more advice about the same problem to see if any further advances had been made.
Fortunately, there does appear to now be some help in the February 2012 CU
which adds or allows access to a new property on the Farm called
XsltTransformTimeout which, by default, is set to 1 second. Using PowerShell we
can update this to cater for high demand peaks in service levels.
Here's the details from a Microsoft SharePoint TechCenter issue: http://social.technet.microsoft.com/Forums/en-US/sharepointgeneralprevious/thread/1a38bdff-e40a-4e50-a2e8-47cbcb31cc6b/
Also see: http://support.microsoft.com/default.aspx?scid=kb;EN-US;2639184 for symptoms and also the MSDN blogs: http://blogs.msdn.com/b/joerg_sinemus/archive/2012/03/07/xslt-and-timeout-problem-when-transforming-runs-more-than-one-second.aspx.
