| 
  • If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • Introducing Dokkio, a new service from the creators of PBworks. Find and manage the files you've stored in Dropbox, Google Drive, Gmail, Slack, and more. Try it for free today.

View
 

Performance Enhancing Products

Page history last edited by Elizabeth Leddy 9 years, 7 months ago

Below is a list of addons that help workaround known performance potholes in plone, many of which have been fixed in the latest version. A lot of us are stuck on our good old plone installs so I'm keeping this page around for you. And me.

 

Be aware that these packages can be for experienced peeps only, since they require a good understanding of the problem in order to configure the fix.

 

Plone 2.5

  • experimental.catalogqueryplan helps plan better queries, rdbms style
  • experimental.contentcreation helps eliminate unnecessary indexing
  • experimental.daterangeindexoptimisations helps with the inefficiencies with date indexes 
  • PloneQueueCatalog (also Plone 3) lets you defer unnecessary indexing until a later time. Perfect for high write sites and helping with ConflictErrors (are you seeing a pattern yet? hint: it rhymes with INDEXING)
  • experimental.portalfactoryfix (also Plone 3) if you are heavy based in archetypes, this should help with archetypes overhead in the creation of objects by caching heavily used components in archetypes
  • MailDropHost is for those that are starting to see transactions retry multiple times.  If you are trying to send an email and the transaction retries, chances are that you will get multiple emails sent. MailDropHost does this asynchronously, which as we already discussed is "yay!", so as to avoid multiple emails. AFAIK, this is not an issue for later version of Plone. Sending an email in python IS NOT CHEAP either way so even if you don't have multiple email issues, if you are sending lots of emails you may want to look into this product. It was a life saver for us old school ploners back in the day.

Plone 3

  • experimental.opaquespeedup helps with unnecessary event overhead

  • collective.indexing takes a lot of the tools that you see above for plone 2.5 and combines them for plone 3

  • collective.solr - if you are not happy with the speed of indexes, you can install another index to take over your SearchableText indexes called solr (Apache/Lucene). While it won't take over the management of solr for you, it will integrate it filly into Plone.

  • Products.BooleanIndex

  • unimr.compositeindex - "CompositeIndex is a plugin index for the ZCatalog. Indexes containing more than one attribute to index an object are called "composite index". Such indexes should be created if you expect to run queries that will have multiple attributes in the search phrase and all attributes combined will give significantly less hits than the any of the attributes alone. The key of a composite index is called "composite key" and is composed of two or more attributes of an object."

  • Chameleon is supposed to make page template rendering much faster by compiling ZPT down to bite code. I haven't used this so I'm not sure on version requirements/actual benefits.

Comments (5)

(account deleted) said

at 11:07 am on Dec 19, 2009

catalogqueryplan has a bit of a description at http://pypi.python.org/pypi/experimental.catalogqueryplan.

The other experimental.* packages are various internals and luckily are all obsolete with Plone 4. They have been integrated and improved in Plone or Zope itself.

Other things to mention:

collective.indexing
collective.solr
Products.BooleanIndex
unimr.compositeindex

Nejc Zupan said

at 4:05 am on Dec 20, 2009

What about Chameleon (http://pypi.python.org/pypi/Chameleon)? Anyone using it in production?

(account deleted) said

at 7:25 am on Dec 20, 2009

I've tested Chameleon quite a lot with both Plone 3.3 and 4.0. But so far we haven't used it in production. In practice it cuts down page rendering times by something like 10 to 50ms depending on the complexity of the page. There's more savings on rendering an /edit page than there's for normal page views. But it only helps with cutting down the rendering overhead. The overhead of more and more content and a bigger catalog is still there and in larger sites much more problematic than base page rendering times. But give it a test :)

Kapil Thangavelu said

at 8:03 am on Dec 20, 2009

also experimental.portalfactoryfix for archetypes content creation. I've had mixed results with portalqueuecatalog and compatibility with cmfeditions.

Elizabeth Leddy said

at 11:32 pm on Jan 11, 2010

thanks for all the comments - I am integrating all these in but feel free to add more info since I haven't used them all

You don't have permission to comment on this page.