Radiant performance issue and how I fixed it.
I implemented the Dutch Fly Fishing site http://www.ffinfo.nl using Radiant. It was a very good project and with Radiant we have a great CMS. However, after some time the site started to slow down considerbly and I started on a quest to improve the performance.
My first step was to investigate on the extensions used that are using a lot of resources and or nested pages. I’m using the Aggregation extensions quit heavily, but removing the use of this extension did not help. An other extension that I use is PageAttachments, in the log files I see that the images ’served’ by the PageAttachments are no bottleneck.
The next step was added RAM and CPU power. The site is hosted on Slicehost, when we had the performance issue it was on a 256 slice. So the next logical step was upgrading to a 512 slice and adding more mongrels to the cluster. This was not really helping, the processing was faster of-course, but there was still something that caused the site to be really slow.
Then something hit me… what about recursion? a quick look into my snippets and I finally found it. I overlooked it completely, but the menu snippet that I used was quering all the pages recursivly for (almost) all the pages in the system. When I removed the recursion the site was as fast as it was when we first started.
An example of what this looks like is displayed below. (sorry for the makeup, this is something that is open for improvement on WordPress)
In the layout:
<div id="menu">
<r :find url="/nl/">
<ul class="adxm menu">
<r :snippet name="menu" />
</ul>
</r>
</div>
The “menu” snippet:
<r :children:each>
</r><r :unless_content part="no-map">
<li> <r :link />
<ul>
<r :snippet name="menu" />
</ul>
</li>
</r>
This kind of code could be used for a sitemap. In fact we still use similar code for rendering our sitemap. This page is the slowest of the site of course
So, this little episode shows that small amount of “smart” recursive code is easily overlooked and can lead to quite some problems.
It seems the sitemap snippet is at fault for a lot of performance crunches. KCKCC, where I originally implemented the sitemap, has gone to a flattened (i.e. static) sitemap now. I imagine search bots crawling that page brought the site to its knees.
Sean Cribbs
24 January 2008 at 11:32 pm