tags:

views:

299

answers:

5

We have one large xslt that renders a whole shop area including products, manifacturers and does filtering based on price and cateogry on top of that. I'm using sitecore as a CMS and I'm having problems with caching. I have about 9000 items and some pages take as much as 20s to render. Will it be better to split the xslt into smaller parts? Does it improve speed?

I think the xslt engine sitecore uses is called Nexus.

Update:

I think we need to optimise the xslt. Even though there were about 9k items the sitecore profiler showed we're actually traversing about 250k items while doing various checks.

+1  A: 

Sounds like the problem is with sitecore not XSLT (I've done faster transforms against 10's of K rows), but I'd advise splitting generally to enable code reuse.

annakata
+4  A: 

Hi,

you probably get a better performance by applying other changes than splitting the XSLT file. Without seeing the XSLT it is hard to spot bottlenecks but you will find some best practices for XSLT performance here:

http://www.dpawson.co.uk/xsl/sect4/N9883.html#d15756e150

In addition it might be very helpful to use an XSLT profiler in that case.

Some performance tricks also depend on the engine that you are using, so some additional information might be useful here as well.

If you could post your XSLT code I might help you in finding possible bottlenecks.

0xA3
A: 

There are two different issues here:

  • Separating XSLT files for better readability, maintainability and code reuse
  • Making performance improvements on your XSLT translations

The first should be done as a best practice, the latter should take care of the extended rendering times you are getting

Yuval A
+1  A: 

Separating one huge rendering into smaller ones will help if you use Sitecore caching. Having multiple renderings will allow to apply individual cache settings to each.

Alexey Rusakov
A: 

Definitely use as small of XSLTs that make sense. Thats just good practice and can't hurt performance.

BeaverProj