LEP/Chameleon

Not logged in - Log In / Register

Change Launchpad to Use Chameleon ZPT Implementation in Lieu of Zope's

Chameleon (http://chameleon.repoze.org/ and https://bugs.launchpad.net/chameleon-template-engine) is a template engine that re-implements Zope Page Templates. As the documentation describes:

These speed claims are repeated in other contexts; Plone developers, for instance, report an increase in Plone (measured in requests per second rather than raw time to serve) that ranges from about 33% faster to more than 100% faster.

Contact: Gary Poster
On Launchpad: https://launchpad.net/launchpad-project/+bugs?field.tag=chameleon

As a Launchpad developer I want faster server-side generation across the board by switching to Chameleon so that Launchpad's users are happier and Launchpad's hardware resources are used more efficiently.

Rationale

A Launchpad developer reports that tests seem to show that switching to Chameleon can give us about a 15% speed increase on the server-side generation time of representative pages. Other projects report a 33 to 100% speed increase on their representative pages by switching to Chameleon.

A squad should need no more than a couple of weeks to iron out the remaining test failures to see if Chameleon can make a difference for us. The cost to benefit ratio at the start of the project might not have been high enough to justify, but this proposal argues that it is justifiable now.

Beyond the potential speed increase that Chameleon offers, Chameleon is also more pluggable. For instance, the "cache:" tales expression we have now was tales (tal:content="cache:...") and not tal (tal:cache="...") because it was not easy to plug in new tal components. Chameleon supports this much better, so we can contemplate making experiments in our templating language more easily and more flexibly.

Details/History

Sidnei da Silva partially integrated Chameleon into Launchpad in 2008. Tests never completely passed, and other projects were given priority within the Launchpad team.

Gary Poster ran tests at the end of 2009 (on staging, turning off other processes, comparing ten representative pages with and without Chameleon; full results not available, unfortunately) that seemed to indicate that Launchpad pages might get a typical win on the server of around 15%. While that is a significant across-the-board improvement, other tests indicated that bigger parts of our overall page speed were in the network traffic, including SSL handshaking. Chameleon looked like something to get to eventually, but not a high priority.

With the increased focus on server-side generation speed that Launchpad's TA brought to the second half of 2010, Gary revisited that decision, and decided it would be nice to try and pick up these changes. He investigated the state of the incomplete Chameleon at that time and made some progress, described in the "Status" section near the bottom of this document.

Risks

Chameleon may not be measurably faster, or may have some killer problem, or may have enough smaller problems that they outweigh any incremental speed gain. We need to be aware that we might need to cut bait on this project. See the "Gotchas" listed in the Status section near the bottom of this proposal for known smaller problems as of this writing.

Stakeholders

Robert Collins, Launchpad's TA, is regarded as the primary decision maker as to whether we should pursue this proposal.

We should pursue this; jml will schedule it into the features queue once drafting of the LEP is complete. -- RobertCollins

Constraints and Requirements

The change must support all current Launchpad features. It must be measurably faster, and the encountered bugs must be either addressed or documented and worked around.

Success

Launchpad must have measurably faster server-side generation after , as measured by our performance reports, for instance.

Bugs are at: Bugs for this LEP

How will we know when we are done?

Chameleon is tested and rejected, or deployed and hardened.

How will we measure how well we have done?

We will use localized server-side performance reports on a selected production test machine to see before-and-after performance. We should be able to switch between Chameleon and Zope implementations with a simple environment change and restart. This will give us the most numerically reliable measurements.

We also ought to be able to see a change in the server-side performance report (https://devpad.canonical.com/~lpqateam/ppr/) across the board once Chameleon is deployed. This might give us more feel-good fuzzies.

Thoughts?

Status

In the course of working with Chameleon and Launchpad, Gary identified the following "gotchas" and changes to be aware of.

Rough suggested schedule

LEP/Chameleon (last edited 2011-01-14 22:34:21 by jml)