[Framework-Team] Re: Some preliminary Plone 3.0 profiling results

Alexander Limi limi at plone.org
Tue Nov 14 14:12:40 UTC 2006


For completeness, I did the same test for the edit tab on the front page:

EDIT TAB: 10 loads of front page, in seconds

Template                                Total  Hits Per hit
===========================================================
ATContentTypes/atct_edit.cpt            11.883  10  1.1883
contentmenu.pt                          3.4623  10  0.3462
plone_javascript_variables.js.pt        0.044   10  0.0044
portlet_navtree_macro.pt                0.0951  10  0.0095
kupu/common/kupudrawers/drawer.xsl      1.2536  20  0.0627
kupu_plone_layer/emptypage.pt           0.7291  10  0.0729
portlets/browser/templates/column.pt    2.9159  20  0.1458
portlets/portlets/classic.pt            2.7526  50  0.0551
portlets/portlets/events.pt             0.0205  10  0.0021
portlets/portlets/login.pt              0.005   10  0.0005
portlets/portlets/news.pt               0.0181  10  0.0018

If there's any way we can improve this, it would be very welcome, as this  
is a big part of what makes Plone feel slow in actual use - the edit part.

— Alexander

On Tue, 14 Nov 2006 05:53:11 -0800, Alexander Limi  
<limi at plone.org> wrote:

> Some preliminary results of running a quick PTProfiler session on Plone  
> 3.0 and trying to figure out what is slowing it down.
>
> I was prompted to do this when I discovered that anonymous view of Plone  
> 3.0 was about 30% slower than 2.5. Take these numbers as a general guide  
> only, it's still early in the 3.0 process, and there's bound to be lots  
> of improvement potential here.
>
> ANONYMOUS: 10 loads of front page, in seconds
>
> Template                               Total  Hits Per hit
> ==========================================================
> document_view.pt                       3.9707  10  0.3971
> plone_javascript_variables.js.pt       0.0441  10  0.0044
> portlet_navtree_macro.pt               0.0899  10  0.009
> portlets/browser/templates/column.pt   2.3798  20  0.119
> portlets/portlets/classic.pt           2.0051  50  0.0401
> portlets/portlets/events.pt            0.0221  10  0.0022
> portlets/portlets/login.pt             0.2678  10  0.0268
> portlets/portlets/news.pt              0.021   10  0.0021
>
> Breakdown of document_view shows (same order/units as above):
> path: plone_view/globalize             0.232   10  0.0232
>
> The rest of the things here use much less time, but there's probably  
> some interesting things there too.
>
> It seems the portlets stuff is what is making it slower (more about that  
> below), along with globalize.
>
>
>
> LOGGED IN: 10 loads of front page, in seconds
>
> Template                               Total  Hits Per hit
> ==========================================================
> contentmenu.pt                         3.476   10  0.3476
> document_view.pt                      10.563   10  1.0563
> plone_javascript_variables.js.pt      0.0464   10  0.0046
> portlet_navtree_macro.pt              0.0934   10  0.0093
>
> portlets/browser/templates/column.pt  3.0892   20  0.1545
> portlets/portlets/classic.pt          2.9249   50  0.0585
> portlets/portlets/events.pt           0.0211   10  0.0021
> portlets/portlets/login.pt            0.005    10  0.0005
> portlets/portlets/news.pt             0.0183   10  0.0018
>
> Breakdown of document_view shows (same order/units as above):
> path: plone_view/globalize            0.8519s  10  0.08519s
> python: [history[i] for i in (…)      0.8055s  10  0.08055s
>
> So for logged-in, "globalize" and the versioning stuff seems to be the  
> two biggest offenders by an order of magnitude, and seem to both take  
> about the same amount of time.
>
> The portlets also seem to be inefficient both for logged in or not, but  
> a lot of this time is spent in classic.pt, which we should be able to  
> eliminate (since we should convert all the portlets to new-style  
> portlets before shipping the release). I'm not sure if column.pt  
> wraps/includes the classic.pt time.
>
> Of course, all this might be wrong, but that's what happens when you let  
> the UI guy do your benchmarking. ;)
>



-- 
_____________________________________________________________________

      Alexander Limi · Chief Architect · Plone Solutions · Norway

  Consulting · Training · Development · http://www.plonesolutions.com
_____________________________________________________________________

       Plone Co-Founder · http://plone.org · Connecting Content
   Plone Foundation · http://plone.org/foundation · Protecting Plone
 





More information about the Framework-Team mailing list