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.

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

7. ALTERNATIVE
persistent.Persistent

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!