High-Performance Applications in Plone Using Persistent
•
0 likes•57 views
The document discusses using persistent.Persistent objects from the ZODB instead of Plone content types to build applications in Plone when performance and scaling are concerns. It provides an example of reimplementing a content type storing data in tables as persistent objects stored in BTrees, which resulted in updates being over 10 times faster. While losing integration with some Plone features, this approach allowed non-Plone developers to work on the application and achieved much better performance scaling to thousands of data items.
More Related Content
What's hot
What's hot (13)
Similar to High-Performance Applications in Plone Using Persistent
Similar to High-Performance Applications in Plone Using Persistent (20)
Recently uploaded
Recently uploaded (20)
High-Performance Applications in Plone Using Persistent
- 1. PERFORMANT APPLICATIONS IN PLONE David Bătrânu Eau de Web
- 2. CURRENT MINDSET • Structure the application using content types. • Hope it doesn’t need to scale.
- 3. BENEFITS • You get a lot of stuff for free. • Full integration with Plone.
- 4. DRAWBACKS • You get too much stuff! Whether you want it or not! • Slooooow!
- 5. SIMPLE EXAMPLE A table!! • Table(Container) - application instance • TableRow(Item) - application data • Catalog for sorting and filtering
- 8. • Most lightweight way to store something in the ZODB • Extremely fast!
- 9. SIMPLE EXAMPLE Same presentation table • Table(Container) - application instance • rows = OOBTree() • TableRow(Persistent) - application data • sort and filter for sorting and filtering
- 11. ACTUAL USE • DX item containing a few fields, used as data in a table. • Requirements grew from tens of items to hundreds. • Managed in bulk through a custom upload view. • ~1s / item update; ~10m for an average update. • Actually thought about using async jobs!!!
- 12. REIMPLEMENTATION • New class extending Persistent • Fields as attributes • Stored in BTrees • <1s to update 10000 items!!
- 13. BENEFITS • MUCH faster!! • Reduced stack complexity - no more async. • Reduced resource usage - no more wasted time. • Easier to test. • Non-Plone people can work on it!
- 14. DRAWBACKS • No OOB permission checks - have to make sure that returned data should be accessible to the current user. • No content management - have to implement add/edit/delete forms. • No workflows, versioning, content rules, etc.. • Basically, not a content type!
- 15. AND THAT’S A GOOD THING • Not all applications should follow this pattern. • In this case, the requirements were better served this way.
- 16. Thank you!