z3ext performance

I have to make a presentation about z3ext internally and performance is something that is expected to be discussed. Few people ever heard about Zope and ZODB.
Since there is no public performance data for z3ext I thought about using various Plone performance presentations (and also some ZODB only benchmark) to build the case.
My question is whether z3ext is comparable to Plone in performance. faster? slower? sort of the same?

Thanks

z3ext adds special http header to response X-Generated-Time. you can check it with firebug or similar tool. this header indicates how much time page being generated.

Our experience is that Z3ext is significantly faster than Plone. The inherent slowness of Plone is one of the major reasons that Z3ext was developed.

Thanks for the replies. For now the performance discussion is on hold and knowing that it is at least faster then Plone is good enough for the moment (considering there are high traffic sites using Plone)

It would be of great help to have forward-cache support as in Plone's CacheFu - Squid or Varnish can handle hundreds of requests per second on a machine which can handle far less with even the simplest z3 app.

Also, the publishing model of zope - 2 or 3 - makes this super simple.  If controlling headers, may as well have a policy-based system and handle purges.

this will work if your page doesn't have much of dynamic data, or you will need load different part of page with ajax. 

There is definitely a lot of overlap between the approach of z3ext.cache and CacheSetup in Plone..

It's just, yanno, Squid can go easily a hundred times faster than bare Zope can serve an empty template with no TALES expressions.  In order for this to work well, however, it's important to be able to use the PURGE command on the Squid, Varnish, Apache, or other HTTP cache.  Then, you can far more easily tier Squid caches than cluster Zope, so if you need to handle a million anonymous hits per day, but only a few thousand logged-in, you can have reasonable performance without any caching in Zope, while logged-in user performance is not impacted by surges of public traffic - there's nothing worse than not being able to update your website because people are rushing to argue in forums over a typo. ;)

Further, it's possible to configure several different cache policies, each with the complexity of z3ext.cache site-wide, for memory caching and headers, and associate them with content types.

It's definitely worth looking into for inspiration of goal, more than implementation, as CacheSetup itself is some crazy Archetype Configlet - the real work is done in CMFSquidTool, PolicyHTTPCacheManager, and a couple others, though we never brought memcached default as you have - very useful with unsticky clustered zope, as memory caches aren't synced.

I will admit, though I have done some testing to substantiate the numbers above, alan runyan has claimed in the past that the zope3 implementation of entransit competes with squid / varnish caches, and it certainly does more than serve a template with no TALES expressions, applying some XSL against XML content from MySQL or something..

Entransit, however, is a completely separate front-end, and http caches are not only simpler, but support for HTTP caches can make it trivial to integrate with Provider-based CDN options.

we found that in really dynamic application it's very hard to determine when you need run PURGE command. to run purge you have to know all possible variables that affect current page view, and in many cases this is almost impossible or is very very hard except simple cases. so i don't think caching whole page is good idea. 

There are multiple solutions to this concern, some loads simply can't be handled by any dynamic platform, whatsoever, and when the use case calls for it, design and information architecture can work around these problems.

BTW, a good example here is being Slashdotted or Dugg. My configuration for siggraph.org handled a strong Slashdot, while editors and visitors of hundreds of other SIGs, Chapters, etc.. noticed no difference. Using CacheFu, we enacted a temporary policy in fact to cache some dynamic views for 5min, which reduced the load by more than one order of magnitude.

Even if z3ext can handle this sort of load on a nice config, editors and other visitors will feel it. Squid, Varnish, etc.. are your friend, for sure. You can tell them to leave you alone, or configure some sites via Apache not to use them, but when you need them, it's nice to have that checkbox handy. ;)

Of course, I'm happy to spend some time sharing what I learned while working with CacheFu, a solution for z3ext would be very different, but should meet similar goals, I'd hope!