Elizabeth Leddy: Unloading Plone: Approaching Scalability in Integrated Plone Systems

While there is an abundance of documentation on ways to achieve better performance with Plone, there is nothing quite like actually doing it, especially with other system components getting in the way. This case based look at the performance and scaling of Plone as part of an integrated system will cover perceived front-end latency, system stability as related to Plone responsiveness, and how to set up a hardware forward architecture. This talk is meant for designers and integrators of large Plone installations.

Plone is slow and that is fine, we just have to deal with it. We are not Drupal. Scalability is talent plus hardware. You are going to require a lot of hardware.

Measure. If you don't know what is going on, you don't know how to act. Use tools like Munin. It records all activities on your system over time. Monit restarts your stuff when it goes down, or sends emails. Ganglia is an alternative to munin. Zope Health Watcher, has munin plugin.

Add whale watchers. Are triggered by system anomalies and collect info about the system at that time.

Shard you zeo: split it into several little zodbs with mount points; at least to this for the portal_catalog. You don't want to move a 300GB Data.fs. Tune your zodb caches. Watch out: do not copy stuff from one shard to another; you will lose stuff.

You want to use 50 percent of your system on average. That way you can add another zope instance quickly when you get a traffic hit.

2 zopes per cpu. The system is better at context switching than zope, so you probably want just one or maybe two threads per zeo client.

See if you can do some processing at another time, so not when saving an object.

Serve static content from a static web server. Apache is better at server all those icons than Zope.

Use css sprites.

Use HAProxy, it is really, really awesome! It has graceful reloads, it knows if a zeo client is ready with a previous request, you can configure a warmup time (give zope the time to startup without hammering it with requests).

When you display data from a different server (like SQL) add tal:on-error to display something else when it goes wrong.

For third party services, do socket.settimeout(2) (if using python lower than 2.6).

Restarting Zope is not a sin. Use monit to restart zope when it takes up too much memory.

A packed zodb is a happy zodb. Do it for your system, it will love you.

On backups:

• use repozo for backing up
• get some sweet disks to make the zodb faster
• think about when you are going to pack your zodb, don't do it when everyone is busy using your server

Suggestions from the room: zeoraid, crickets, zenoss, munin.zope.