My life with Plone, part 4

Continues parts 1, 2, and 3.

Add-on products

In the Zope world a “product” is more or less equivalent to an “add-on” or a “plugin” in comparable frameworks — the encapsulation of some functionality that extends the core system by “installing” it though a standard procedure.  The CMF is actually a bundle of products that extend Zope, and Plone is largely built on the CMF. Over time, more and more products originally built on the CMF (placeful workflow) or Zope 2 (external editor) have been bundled with Plone, and some of those have integrated with Plone’s management UI.  This is generally good; in fact, for future compatibility reasons, I tend to prefer sticking as closely as possible to Plone’s distribution product bundle and minimizing the number of additional products added to the system. This of course limits the functionality I can offer to users, but also limits the risks. If you install a product that is not shipped with Plone you should be prepared to support it yourself.

Performance and caching

I find this excerpt from the article Plone patterns and best practices on plone.org says it well:

Here’s a little fact we should admit up front: Plone is slow. Not as slow as it used to be, not as slow that it’s useless, but neither Zope nor Plone have ever been sold on speed. In general, Plone is a content production system, not a content delivery system, and has been written for features and ease-of-use — not for blazing speed. (We use caching to improve speed, or separate delivery platforms altogether.)

[Author’s emphasis; accessed 23 December 2008.–DCS]

Performance can be a significant, if solvable, problem with Plone and there are many strategies for dealing with the issue. Finding the best solution, however, for the your particular system requirements and combination of time and skills can be a challenge.  Fortunately, changes since Plone 3.0, such as greater reliance on catalog data, have improved out-of-the-box performance. OTOH Plone makes very heavy use of CSS and JavaScript, and I’ve found that one of the biggest performance boosts comes from front-end caching of this content. I use mod_cache in Apache 2.2 for this and it works well. Zope 2 has long had integrated caching capabilities, but the machanisms for applying them (via the ZMI) are rather crude.  CacheFu promises an integrated Plone solution, but I encountered a roadblock in version 1.1.2 that prevented me from implementing it in my system.

If you have a zoecluster installation with a front-end proxy server, then you can also implement simple load balancing. I use three zeocluster clients, two for user access and one for administrative tasks such as updating the catalog. With Apache and mod_proxy_balancer I can distribute requests between the first two clients:

<Proxy balancer://zeocluster>
    BalancerMember http://localhost:8080
    BalancerMember http://localhost:8081
    ...
</Proxy>

RewriteRule ^/(.*) balancer://zeocluster/VirtualHostBase/https/my.host:443/plone/VirtualHostRoot/$1 [L,P]

I should mention that PTProfiler is indispensable for diagnosing performance issues in Zope page templates. More than once I have been able to isolate a performance problem in my own code using this tool.

The community

The Plone community is large and very international. On the whole I would say my experience has been about average for an open source project — that is, sometimes there’s good help, sometimes not.  Because of the complexity of a Plone installation — including Python, Zope, Plone, third-party products, customizations, etc., not to mention external systems such as Apache, LDAP, etc. — troubleshooting problems can be tricky and knowing to whom a problem is best addressed isn’t always clear.  Again, this is why I prefer to stick close to the distribution: If I have a problem it’s more likely not to be my fault, and maybe there’s a better chance I can get help.

Advertisements

, , , ,

  1. #1 by Alexander Limi on December 23, 2008 - 4:49 pm

    You probably know this already, but there’s significant effort being invested into radically improving performance of Plone 4.

    The current benchmarks show that the team has already made Plone 4 three times faster than Plone 3:

    http://blog.hannosch.eu/2008/12/plone-trunk-versus-kcachegrind.html

    …and we’re not done yet. 🙂

  2. #2 by David Chandek-Stark on December 23, 2008 - 7:53 pm

    Actually, I didn’t know, so thanks for the response. That’s good news.