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:

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 

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

Zope maillist  -  Zope@zope.org
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-dev )

Reply via email to