• Like
  • Save


Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

High performance sites made easy

Uploaded on

The Zope Component Architecture is a very powerful tool which is widely used in Plone and the Plone community. For stock users of Plone it can seem like an encumbrance, slowing the site down and …

The Zope Component Architecture is a very powerful tool which is widely used in Plone and the Plone community. For stock users of Plone it can seem like an encumbrance, slowing the site down and complicating development without any advantages. However, even basic applications built with Plone can benefit from some ZCA tricks that are not as widely known as they should be.

This talk will demonstrate simple uses of the component architecture which, along with a typical Plone stack, allow developers to deliver very performance Plone sites while simultaneously freeing the developer from the normal optimisation worries.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads


Total Views
On Slideshare
From Embeds
Number of Embeds



Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide


  • 1. www.jarn.com Matthew Wilkes Jarn
  • 2. www.jarn.com High Performance made easy Some tips and tricks that defy conventional wisdom
  • 3. www.jarn.com About me Matthew Wilkes Former Bristolian living in Berlin Working at Jarn Plone 4 FWT member
  • 4. www.jarn.com Old wives’ tales
  • 5. www.jarn.com Performance ‘is’… … never waking an object … avoiding adapter lookups … heavily optimising your python code
  • 6. www.jarn.com What’s really important • Planning • What will be the profile of reads/writes be? • Agility • Defer optimisation as late as you can
  • 7. www.jarn.com What’s really important • Cacheability • Can the design be made more cacheable? • Analysis • Real world numbers, not just profiling code
  • 8. www.jarn.com Know your users Find out expected usage patterns Are accesses distributed evenly or are there some content hotspots? Are you using the right technologies for the load?
  • 9. www.jarn.com Heard it on the grapevine! FACT: The catalogue is fast MYTH: “You should never wake objects”
  • 10. www.jarn.com BURN HIM
  • 11. www.jarn.com No, really. Look. Single attribute, known location 200 What if we want some basic 160 information from some 120 specific objects? 80 Waking them is faster for up to40 about 50 objects 0 0 10 20 30 40 50 60 70 80 90 Traversal Catalogue
  • 12. www.jarn.com No, really. Look. 5 attributes, known location 100 80 Or we might want to show a folder listing 60 40 Catalogue is faster for much smaller object sets 20 0 0 10 20 30 40 50 60 70 80 90 Traversal Catalogue
  • 13. www.jarn.com I should forget the catalog? NO! Remember agility. Not catalogue specific, make more decisions based on real numbers. Until you’ve written your code you don’t know if you should use the catalog or not.
  • 14. www.jarn.com Become a catalogue agnostic
  • 15. www.jarn.com Photo: Kevin Dooley (be indifferent to brains)
  • 16. www.jarn.com What does that mean? Catalogue brains are very different to real objects We can’t call methods The same data is exposed differently ZCA is designed to allow us to be implementation agnostic
  • 17. www.jarn.com Tip: Register an adapter! Your content has an interface anyway, right? Register an adapter from ICatalogBrain to it Implement data from the catalogue directly Use a custom __getattr__ to allow fallback
  • 18. www.jarn.com Tip: Register an adapter! Your code doesn’t know if it is dealing with a brain or a real object – your catalogue fiddling is deferred Reduces the amount of stuff you need to keep in your head
  • 19. www.jarn.com
  • 20. www.jarn.com Real numbers Use Apache CustomLog or HAProxy logs to get request times Good: If you’re iterating with a customer run it there Better: Soft-launch with a subset of users and run there!
  • 21. www.jarn.com Varnish HTTP Cache HTTP caching is the single most powerful trick we have Improves read performance by 2-3 orders of magnitude Leaves the instances free for writes
  • 22. www.jarn.com Anonymous users Easiest to cache for - Varnish + plone.app.caching Almost everything can be kept in the cache Need to balance longer TTLs with difficulty of getting PURGE right.
  • 23. www.jarn.com Authenticated users Only images, JS and CSS cacheable at first glance Pages refer to the username and some things are role dependent. No way to solve this problem in the general case
  • 24. www.jarn.com Page composition But we don’t care about the general case We know the site we’re making Use ESIs to separate content that varies between users from the common things
  • 25. www.jarn.com If we didn’t plan out what parts of each page are cacheable it might be impossible to split it out efficiently. Keep the blocks that are user-specific small, few and separate. Make those sections send cache-control: private The main page should send cache-control: public
  • 26. www.jarn.com Tip: Use ESI Easy to hack into existing sites if you’re in a pickle Can bring authenticated accesses up to the same speed as cached anonymous users
  • 27. www.jarn.com Tip: Make use of views Any template code backed by a Python class will do. Custom __call__ method that checks for a header turning on ESI and if it is being rendered directly Return an ESI tag or the full content Makes it easy to enable/disable if needed
  • 28. www.jarn.com Change is good
  • 29. www.jarn.com Often the big changes in terms of performance are small changes to the client Should a page have 5 items or 20? Can we simplify the workflow? Both cut down the number of page loads needed
  • 30. www.jarn.com Any questions?