N.Davis wrote:
Jean-Marc Orliaguet wrote:
Hi!
I usually don't read the posts on zope-list, but I found this one: http://mail.zope.org/pipermail/zope/2005-September/161330.html
sorry this is a bit old, but ...
M. Davis, what are your benchmark figures based on?
I just ran a quick benchmark on Plone's front page and found:
siege -v -r 10 -c 1 http://localhost:8080/plone ** siege 2.61 ** Preparing 1 concurrent users for battle. The server is now under siege...
Jean-Marc, Hello. To be honest I didn't actually benchmark this scientifically. So very sorry if I did a bad thing and made a statement against the performance of CPSSkins that is not actually true.
Hi Nick! Again I think that you are assuming things...
I liked the look of CPSSkins, but looked into it a bit and thought, this does too much , its too clever. That means the rendering is more complex which will hit performance. Also a sophisticated product is possibly more likely to break doing a migration such as to Plone 2.1.
the support for plone2.1 will be available soon, when I get the time to do a release. The actual changes to support plone2.1 are trivial, basically small API changes and a new template for the preference panel. They are summarized here: http://svn.nuxeo.org/trac/pub/changeset/24294 So If plone2.1 was to cause CPSSkins to break it would also break the hundreds of thousands of sites that have customized the plone skins.
Its a more complicated product to maintain perhaps. Thats not entirely scientific either because something well-written by good programmers who understand Plone well may be more "migration-proof" than a simpler but sloppier-written Product. But I take an attitude that while Zope/Plone is great, a certain amount is still bleeding edge and brittle, so don't try to be too clever. My colleague got burnt by pushing the limits of a bleeding edge version of Archetypes (1.2.5). We're still struggling to migrate to 1.3.4. On the other hand some people need to push the limits in order that advanced features get their bugs found and fixed.
I think that I usually spend about 1 hour a month on the Plone version of CPSSkins, keeping up with the changes in Plone. CPSSkins works on CMF, CPS, plone so 95% of the code is completely independent of Plone. The only part that needs to be updated are the skins located in http://svn.nuxeo.org/trac/pub/browser/CPSSkins/trunk/skins/cpsskins_plone2/
Plone performance tuning is something I need to learn more about when I get time. If a Product can perform well with tuning thats great but it can be an issue if its default behaviour is a performance hit and it therefore imposes a performance tuning requirement. (Not implying that this is true of CPSSkins).
the biggest performance hit in plone comes from the fact that the product relies too much on zope page templates, which 1) where not designed to be cached by fragments 2) they use methods located in user space (python scripts, etc) and 3) the page template architecture needs to get all the parts rendered before the entire page can be displayed, so if one little portlet on the page takes 2 seconds to be render, it is the entire page will take 2 seconds to render. It is very difficult to isolate the slowest parts of the rendering chains.
I guess what you're saying is you do not believe there are performance issues with CPSSkins, and you have evidence of a least one situation to back this up. So, I don't mean to cast aspersions, and I would still consider looking into using CPSSkins in the future. :-) Regards Nick
by design, the performance issues are tackled completely differently, since there are possibilities to cache page fragments. But again the Plone version of CPSSkins is one year behind the CPS version because the portlet caching architecture is missing in Plone. I don't know about PlonePortlets, but last time I tried they worked in CPSSkins. best /JM