High performance sites made easy


Published 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 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.

Published in: Technology
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

High performance sites made easy

  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. What if we want some basic information from some specific objects? Waking them is faster for up to about 50 objects 0 40 80 120 160 200 0 10 20 30 40 50 60 70 80 90 Single attribute, known location Traversal Catalogue
  12. www.jarn.com No, really. Look. Or we might want to show a folder listing Catalogue is faster for much smaller object sets 0 20 40 60 80 100 0 10 20 30 40 50 60 70 80 90 5 attributes, known location 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 (be indifferent to brains) Photo: Kevin Dooley
  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 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 Tip: Use ESI
  27. www.jarn.com 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 Tip: Make use of views
  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?