ZODB notoriously slow on commits

General observation with Plone 5.2 (and Python 3): ZODB commits are notoriously slow

I just reindexed ("Clear and rebuild") as small migration site with less than 100 objects. Reindexing time: one second, 10 seconds for the ZODB commit.

Similar experience with a production portal where we reindex some 300 objects per night (without updating the objects): takes about 3 seconds for retrieving and indexing the objects, 30 seconds for the commit.

That does not well right and is not consistent with the experience from the past.

Anyone with similar experiences?

We have a large pre-production Volto site where we encountered multiple performance related issues. We were able to fix a few (e.g. the zope interface adaptation with @jensens help, putting Varnish in front, which we didn't need in Plone 5.1, fixing multiple requests in Volto, micro-optimizing a few things in the frontend part).

Though, the general observation is that something happened between Plone 5.1 (Python 2) and Plone 5.2 (Python 3) that had some impact on the backend performance.

Though, our site is not small, a Solr Reindex takes > 1h. Haven't checked a "Clear and rebuild" yet, will do.

I'd be open to set up some performance tests to compare the performance of Plone 5.1 and 5.2 and turn guessing into prove. Though, our main concern is performance via plone.restapi.

I already ran these tests but couldn't find any REST API call that takes more than a few hundred milliseconds:

(Just run the performance buildout for the different Plone versions and fire up jMeter)

I also worked on some performance tests for "classic" Plone:

So if somebody wants to pick that up I'd be more than happy to help.

Note that my issue is completely about the transaction.commit().
I have not seen much issues with the overall performance. To be honest: we have no numbers from our largest portals but they behave performance-wise as they should.

Maybe off-topic but observations we had for loading patients via life-search.
We have 4 zeo clients, each with four threads.
Then under certain conditions it loaded the patient twice. First time with a warm thread, 2nd time with a cold thread.

We are now logging the number of cached objects for inspection - in similar way maybe you are shifting thread.

Fair enough, I just did a "clear and rebuild" without Solr and it went through quite fast, so I can not confirm the transaction.commit() problem on our end. Though, I haven't investigated it in any way...general performance discussion should go into another thread then...

@zopyx what if you call:

from Products.CMFCore.indexing import processQueue
processQueue()

before transaction.commit()?

It might be that the queue is still not empty before the commit and that the commit will trigger it.

I don't know anything about the indexing queue...have to check this...this is new to me

To keep it short after this PLIP https://github.com/plone/Products.CMFPlone/issues/1343 index/reindex/unindex operations are delayed until:

  • a catalog search is made
  • a commit is made

So it makes sense now Plone is really fast calling obj.reindexObject() but after that slow in calling transaction.commit().

3 Likes

Plone Foundation Code of Conduct