[Zope-CMF] CMF write performance as poor as Plone?

[Roché Compaan]

On Fri, 2008-11-21 at 07:31 +0100, Andreas Jung wrote:
> Hi there,
> 
> we are currently doing consultancy work for a bigger Zope-based CMS 
> project (lotes of users, lots of concurrent editors/write). Plone and 
> CMF are basically what we are looking into right now. It is well-known 
> that Plone is poor on concurrent write. It is basically impossible 
> creating more than 3-4 objects per second on decent hardware. On 
> observation we made was that Plone causes transaction size of 30k-100k
> per each new object (this is also true trivial changes on existing
> content objects). So I thought this might be a limiting factor and 
> looked at CMF. The transaction sizes under CMF are much smaller - 
> typically between 2k and 4k for new objects or object changes which is 
> looking good at the first glance. However the transaction size does not 
> seem to have any impact on the number of simulataneous writes.
> I wrote script simple script like this:
> 
> results_folder[randint(1,500)].invokeFactory(Document, some_id)
> 
> where result_folder is a btree based folder containing 500 other empty
> btree folders.
> 
> Running 'ab2 -n 100' against the site would create 100 new documents 
> distributed over the subfolder (avoid conflicts errors here).
> The performance was nearly as bad as with Plone. It was hard getting 
> more 4-6 new objects per second out of a standard CMF site (2.1, 
> zope.schema-based types). Even variations of the zserver-threads and the 
> ab2 concurrency level did not help much.
> 
> hmm....so why is CMF here nearly as bad a Plone. In Plone we know that 
> everything is indexed various times (also in CMF I think) but Plone has 
> much more indexes and metadata compared to CMF. A request in Plone goes 
> through much more layers than in CMF....I am currently clueless 
> interpreting the results. My current interpretation is: a custom 
> CMF-based implementation of a CMS will be comparable slow/fast as an 
> out-of-the-box solution?!

I also suspected transaction size a while back but found that it doesn't
really impact on write performance. The one thing that stood out clearly
was the time it takes to index objects. I managed writes of up to 20
objects per second if I created the object with _setObject while
suppressing all events and manually re-indexing the object after
creation. Indexing in Plone improved once we cached the expensive Schema
lookup that is made for each attribute (see discussion on this in
plone-dev) but this shouldn't be an issue in CMF. Maybe there is
something else in CMF that slows down attribute access when objects are
indexed. I can almost guarantee that there is some application code that
slows down writes, since I know now that indexing and object creation is
relatively fast. 

-- 
Roché Compaan
Upfront Systems                   http://www.upfrontsystems.co.za