Can I make my Plone 3.x faster?

In my series of showing of fancy graphs, I have gotten repeated complaints about not caring about Plone 3.x enough. Now I did clarify that many of the improvements we make to Plone trunk are too risky or backwards incompatible to do in Plone 3.x. But some of the improvements have made it back into Plone 3.3.

Most importantly of all Malthe Borch is working like crazy to make Chameleon compatible with the next Plone major release numbered 3.3. He certainly deserves any kind of support you can give him. While Chameleon is not going to be part of the official 3.3 release, thanks to our move to zc.buildout you will be able to install it painlessly into your sites. As with the other experimental.* packages announced at various times, this is still not going to be for the casual user. But if you are an experienced Plone integrator those options are worth checking out today.

Plone trunk has seen another couple of improvements pushing it close to the 50 req/s limit, but taking Plone 3.2 as a baseline, the slogan today is: Plone is getting twice as fast with every release:

Plone trunk continues to get faster

It's been more than two months, since I had a detailed look at the state of Plone trunk performance. This weekend I spent on evaluating what impact the changes we made during that time had on performance and worked a bit more on it.

I made another round of improvements to the way we use CMF actions and converted some of the last Python scripts used in every page to browser view based code. Using as little untrusted code as possible to be part of the page rendering proved once again to be a fruitful endeavor.

My current findings indicate that both the sheer overhead of security checks for untrusted code, but sometimes more importantly the hard to understand and spread out code itself cause the performance problems we have. An example I found today was the language selector viewlet. A nice mixture of code and nesting found in the template, some code in the viewlet class, both backed up by the language tool and querying a language utility in the backend. Each of the pieces looked good in itself, the combination meant that even for a site with a single language a large dictionary of all languages in the world was deep copied, and iterated over twice to determine that the number of languages used in the site was not more than 1. The relevant information here being easily accessible as simple attribute access away on the language tool. Concentrating the control flow from all the different places into the browser view made it far easier to understand what happened and avoid the insane overhead.

Long story short, compared to Plone 3.2 as a baseline, we got up from a factor of being three times faster to about four times faster now.