1.6. com_content 2 times slower than 1.5.

[klas berlič]

Tested 1.5 vs. 1.6 frontend performance with a simple test - 10 runs of frontpage.

Both are default frontpages with no caching - which makes it even worse because 1.5. has 5 modules more activated on current frontage.
It is a slow local server, but the same for both instances:

1.5.
Array (
 [0] => Application Start: 0.000 seconds, 0.88 MB
[1] => Application Stop: 3.830 seconds, 1.36 MB )

1.6.
Array (
[0] => Application 0.000 seconds (+0.000); 1.15 Mb (+1.15) - Start
[1] => Application 6.846 seconds (+6.845); 2.44 Mb (+1.29) - Stop )

[Luis Morales]

Klas,

Hello.  My name is Luis Morales and I got this e-mail through one of the joomla/google groups.  I'm also concerned about J1.6 front-end performance and been doing personal local-server tests with results similar to yours.  I posted an announcement in the Joomla Forum seeking for people with this concern but didnt get any replies; so you can imagine my relief when I saw your e-mail.  I find very disappointing that J1.6 performs so poor, especially when the trend in php frameworks is to seek better performance (e.g.: yii, symfony reloaded, the new solar [forgot the version number], doo, etc). 

I had a development idea of streamlining J1.6's front-end with a very light framework I created once.  I have no problems with J1.6 admin section; actually, for security purposes I prefer the admin as slow as possible (just kidding, but you get the idea).  Actually, I shouldn't say what I did is a framework, actually I call it NAF, for Not A Framework.  It's based on doo and yii, in which you use a single base file to load the most important elements of the system (e.g.: controller, user, document, app, session), and then use lazy load to include other components on a per-need basis.  I thought about using a yii-based front-end, but it turned out to be a hassle to bridge with joomla. 

Please let me know if you are interested in working on a J1.6 lighter version of the frontend.  If so, I want to chip in and collaborate.  I like Joomla so much and it would be a real shame if the front-end is as slow as it seems.  I'm hoping that maybe when they finally release it they fine-tune the performance and it's not as slow.  But if they keep as the way alpha version is, I really think it might be the final blow to Joomla.  Hope to hear back from you.

Respectfully,
Luis

2010/4/2 klas berlič <klas....@gmail.com>

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To post to this group, send an email to joomla-...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-cm...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.

[Niels Braczek]

klas berlič schrieb:

> 1.5.
> Array (
> [0] => Application Start: 0.000 seconds, 0.88 MB
> [1] => Application Stop: 3.830 seconds, 1.36 MB )
>
> 1.6.
> Array (
> [0] => Application 0.000 seconds (+0.000); 1.15 Mb (+1.15) - Start
> [1] => Application 6.846 seconds (+6.845); 2.44 Mb (+1.29) - Stop )

Are you able to do a profiling to find the bottleneck?

Regards,
Niels

--
| http://www.kolleg.de · Das Portal der Kollegs in Deutschland |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · e-Commerce · Joomla! Content Management |
------------------------------------------------------------------

[Hannes Papenberg]

Hmm, then I'm wondering why 1.5, with a borked metric (the time from 1.5
debug actually only measures the rendering time up to and including the
component and not from the modules, template, etc.) takes double the
time on my system compared to 1.6. 0.28s compared to 0.58s

Hannes

[klas....@gmail.com]

I run this from inside com_content controler, so it should indeed measure only com_content performance in both (I was mistaken about modules).

1.5. replaced
if ($user->get('id') ||
($view == 'category' && JRequest::getVar('layout') != 'blog' && $viewcache == 0) ||
$view == 'archive' && $viewcache == 0) {
parent::display(false);
} else {
parent::display(true);
}
with
jimport( 'joomla.error.profiler' );
$p = JProfiler::getInstance('Application');

$p->mark('Start');
for ($i=0; $i<=10; $i++) {
parent::display(false);
}
$p->mark('Stop');

print_r($p->getBuffer());


1.6 replaced $view->display(); with:

$p = JProfiler::getInstance('Application');

$p->mark('Start');
for ($i=0; $i<=10; $i++) {
$view->display();
}
$p->mark('Stop');

print_r($p->getBuffer());



Did this to compare results while measuring cache branch performance..this are momentary results I get (not measured under the same load as 1.5 / 1.6. comparison). First cached result is 9 runs of 10 cached (cache was cleared before measurement so 1st one run uncached) , 2nd is repeat and so fully cached (10 out of 10)

Uncached
Array ( [0] => Application 0.000 seconds (+0.000); 4.46 Mb (+4.46) - Start [1] => Application 8.091 seconds (+8.091); 11.73 Mb (+7.26) - Stop )


Filecache
Array ( [0] => Application 0.000 seconds (+0.000); 4.45 Mb (+4.45) - Start [1] => Application 0.863 seconds (+0.863); 7.12 Mb (+2.67) - Stop )
Array ( [0] => Application 0.000 seconds (+0.000); 4.45 Mb (+4.45) - Start [1] => Application 0.214 seconds (+0.214); 5.25 Mb (+0.80) - Stop )

APC
Array ( [0] => Application 0.000 seconds (+0.000); 4.43 Mb (+4.43) - Start [1] => Application 0.809 seconds (+0.808); 6.94 Mb (+2.51) - Stop )
Array ( [0] => Application 0.000 seconds (+0.000); 4.42 Mb (+4.42) - Start [1] => Application 0.187 seconds (+0.187); 5.22 Mb (+0.80) - Stop )

Cachelite
Array ( [0] => Application 0.000 seconds (+0.000); 4.60 Mb (+4.60) - Start [1] => Application 0.784 seconds (+0.783); 7.11 Mb (+2.51) - Stop )
Array ( [0] => Application 0.000 seconds (+0.000); 4.60 Mb (+4.60) - Start [1] => Application 0.196 seconds (+0.196); 5.40 Mb (+0.80) - Stop )

Memcache
Array ( [0] => Application 0.000 seconds (+0.000); 4.47 Mb (+4.47) - Start [1] => Application 0.825 seconds (+0.825); 6.98 Mb (+2.51) - Stop )
Array ( [0] => Application 0.000 seconds (+0.000); 4.47 Mb (+4.47) - Start [1] => Application 0.184 seconds (+0.184); 5.27 Mb (+0.80) - Stop )

Eacellerator
Array ( [0] => Application 0.000 seconds (+0.000); 1.08 Mb (+1.08) - Start [1] => Application 0.802 seconds (+0.801); 1.53 Mb (+0.45) - Stop )
Array ( [0] => Application 0.000 seconds (+0.000); 1.08 Mb (+1.08) - Start [1] => Application 0.183 seconds (+0.183); 1.23 Mb (+0.14) - Stop )

Xcache
Array ( [0] => Application 0.000 seconds (+0.000); 1.21 Mb (+1.21) - Start [1] => Application 0.758 seconds (+0.758); 1.73 Mb (+0.52) - Stop )
Array ( [0] => Application 0.000 seconds (+0.000); 1.19 Mb (+1.19) - Start [1] => Application 0.175 seconds (+0.174); 1.45 Mb (+0.26) - Stop )



Will try to find the bottleneck


Dne 2. apr. 2010 08:18 je Hannes Papenberg <hack...@googlemail.com> napisal:

[Gary Jay Brooks]

bump - watching.

[klas berlič]

Did some profiling - unpublished all modules so that only com_content was on that page. Also changed default SEF in 1.6. to OFF to make things equal (this made some difference). Also set number of articles to display to the same amount - 5 (btw - had to set an exact amount of articles to featured because links 0 is not working)

To display frontpage (1 run)  it took:

1.5.
Profile Information
Application afterLoad: 0.009 seconds, 0.11 MB
Application afterInitialise: 0.251 seconds, 0.56 MB
Application afterRoute: 0.282 seconds, 0.74 MB
Application Com_content Start: 0.370 seconds, 0.89 MB
Application Com_content Stop: 0.767 seconds, 1.19 MB
Application afterDispatch: 0.769 seconds, 1.16 MB
Application afterRender: 0.808 seconds, 1.20 MB
Memory Usage
1314832

11 queries logged


1.6.
Profile Information
Application 0.008 seconds (+0.008); 0.11 Mb (+0.11) - afterLoad
Application 0.154 seconds (+0.146); 0.50 Mb (+0.39) - afterInitialise
Application 0.234 seconds (+0.080); 0.95 Mb (+0.45) - afterRoute
Application 0.283 seconds (+0.048); 1.10 Mb (+0.15) - Com_content Start
Application 0.947 seconds (+0.664); 1.52 Mb (+0.42) - Com_content Stop
Application 0.974 seconds (+0.027); 1.50 Mb (+-0.02) - afterDispatch
Memory Usage
1,721,680

22 Queries Logged


The difference between 1.5. and .1.6 in queries lies in:

1. SELECT b.rules
     FROM jos_assets AS a
     LEFT JOIN jos_assets AS b
     ON b.lft <= a.lft
     AND b.rgt >= a.rgt
     WHERE (a.name = 'com_content.frontpage.1' OR a.parent_id=0)
     GROUP BY b.id
     ORDER BY b.lft
2. SELECT b.id
     FROM jos_user_usergroup_map AS map
     LEFT JOIN jos_usergroups AS a
     ON a.id = map.group_id
     LEFT JOIN jos_usergroups AS b
     ON b.lft <= a.lft
     AND b.rgt >= a.rgt
     WHERE map.user_id = 0
3. SELECT a.rules
     FROM jos_assets AS a
     WHERE (a.id = 1)
     GROUP BY a.id
4. SELECT b.rules
     FROM jos_assets AS a
     LEFT JOIN jos_assets AS b
     ON b.lft <= a.lft
     AND b.rgt >= a.rgt
     WHERE (a.name = 'com_content.frontpage.6' OR a.parent_id=0)
     GROUP BY b.id
     ORDER BY b.lft
5. SELECT b.id
     FROM jos_user_usergroup_map AS map
     LEFT JOIN jos_usergroups AS a
     ON a.id = map.group_id
     LEFT JOIN jos_usergroups AS b
     ON b.lft <= a.lft
     AND b.rgt >= a.rgt
     WHERE map.user_id = 0
6. SELECT b.rules
     FROM jos_assets AS a
     LEFT JOIN jos_assets AS b
     ON b.lft <= a.lft
     AND b.rgt >= a.rgt
     WHERE (a.name = 'com_content.frontpage.5' OR a.parent_id=0)
     GROUP BY b.id
     ORDER BY b.lft
7. SELECT b.id
     FROM jos_user_usergroup_map AS map
     LEFT JOIN jos_usergroups AS a
     ON a.id = map.group_id
     LEFT JOIN jos_usergroups AS b
     ON b.lft <= a.lft
     AND b.rgt >= a.rgt
     WHERE map.user_id = 0
8. SELECT b.rules
     FROM jos_assets AS a
     LEFT JOIN jos_assets AS b
     ON b.lft <= a.lft
     AND b.rgt >= a.rgt
     WHERE (a.name = 'com_content.frontpage.4' OR a.parent_id=0)
     GROUP BY b.id
     ORDER BY b.lft
9. SELECT b.id
     FROM jos_user_usergroup_map AS map
     LEFT JOIN jos_usergroups AS a
     ON a.id = map.group_id
     LEFT JOIN jos_usergroups AS b
     ON b.lft <= a.lft
     AND b.rgt >= a.rgt
     WHERE map.user_id = 0
10. SELECT b.rules
      FROM jos_assets AS a
      LEFT JOIN jos_assets AS b
      ON b.lft <= a.lft
      AND b.rgt >= a.rgt
      WHERE (a.name = 'com_content.frontpage.48' OR a.parent_id=0)
      GROUP BY b.id
      ORDER BY b.lft
11. SELECT b.id
      FROM jos_user_usergroup_map AS map
      LEFT JOIN jos_usergroups AS a
      ON a.id = map.group_id
      LEFT JOIN jos_usergroups AS b
      ON b.lft <= a.lft
      AND b.rgt >= a.rgt
      WHERE map.user_id = 0

So without digging further in the code - this certainly looks like a cause for a large part of measured time differences.

Regards,
Klas

2010/4/2 Gary Jay Brooks <garyja...@gmail.com>

bump - watching.

[Mark Dexter]

Klas, what is not working with links=0? I just tested and it seems to work fine. Mark

2010/4/2 klas berlič <klas....@gmail.com>

[klas berlič]

Disregard that, probably wrong window I was looking at. Any thought on the results?

2010/4/2 Mark Dexter <dexter...@gmail.com>

[Louis Landry]

I would say that it isn't very unexpected... at least by me.  We haven't even reached beta yet, and we don't have finalized layouts among a few other things.  We have plenty of optimization that can be done with respect to the ACL system, database indexes, and any number of other things to improve performance.  I think that given the fine grained ACL system being added on though that we can certainly expect that first results are going to be slower... as you are noticing.

- Louis

2010/4/2 klas berlič <klas....@gmail.com>

--
Development Coordinator
Joomla! ... because open source matters.
http://www.joomla.org

[Andrew Eddie]

Hi Klas.

Are the default pages set up "exactly" the same (same content, same
modules, same menus)? If they aren't can you create two exactly the
same sites from scratch and put up the sql dumps for people to test?
We need to make sure we are comparing apples with apples before
drawing conclusions (I'm pretty sure the 1.6 default page is a *lot*
heavier than the 1.5 default page). Actually, we should probably
start with the neutral test of no sample data. That would at least
tell us if just loading the framework is heavier/lighter.

Also, details of your test environment would help as well.

Thanks.

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer

2010/4/2 klas berlič <klas....@gmail.com>:

[Wilco Jansen]

Hi,

I ran a quick profile on the latest trunk version of 1.6, the result can be found in the attached graph. It is an hierarchical overview of a default page run; front-end, default 1.6 installation, example data (Svn 15794). Going from top-level down you see that around 60% is spend in the dispatcher, even going lower you will see most time is spend in JComponentHelper::renderComponent (54.25%). It is obvious where the most performance benefits can be  implemented.

Cheers, Wilco

[Andrew Eddie]

Very nice graph. Only thing I'd say, though, is that it should be
normal for most of the time to be spent in the component - in other
words, the less time the framework takes to fire up the better. So I
think we need to optimise the "no load" configuration first (an empty
template), then have an array of test templates to progressively work
the system harder and harder.

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer

[dukeofgaming]

<offtopic>

Hi Wilco. Quick question, what did you use to render that graph?.

Thanks

</offtopic>

[Sam Moffatt]

Looks like it came from xdebug and kcachegrind or similar tool. You
use xdebug to generate the profiles and kcachegrind will build that
sort of a graph for you and allow you to dig through it. It is
invaluable when trying to work out where your bottlenecks are in the
application.

Sam Moffatt
http://pasamio.id.au

[dukeofgaming]

Indeed looks like it is, I could use that to ease my neural call stack =P.

Thanks Sam

[Andrew Eddie]

Klas and Wilco, would you like to work up some testing plans and get
things set up so we can get good data on where any bottlenecks might
be?

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer

On 3 April 2010 18:50, Wilco Jansen <jansen...@gmail.com> wrote:

[dukeofgaming]

<offtopic:again>

Hmmmm, will try this.... http://code.google.com/p/webgrind/

</offtopic>

[Wilco Jansen]

Sam is right, this is a cachegrind file presented in KCachegrind. File is generated from xdebug, and KCachegrind gives you the option to browse the flow (also graphically browsing is possible) down to the code level. Pretty aswesome! See also  http://jfoobar.org/blog/336-profilers-profiles-and-profiling-.html for a short intro on what I used. It is my personal ex;pierence that the Linux install is much easier and powerfull then the Windows equivalent ;-) 

[Wilco Jansen]

November 2008 I did a first performance analyses after Anthony did some major PHP 5 refactoring (see http://www.jfoobar.org/blog/57-first-look-at-joomla-16-refactory-speed-and-caching.html). When I posted the reply in this mail thread I redid the same testing, I used the basic outcome in my last blog post. I  noticed speed differs (obvious, since I use different hardware) but also a double the amount of the memory usage! I have taken a closer look, and notice that the CMS/Framework loads all classes it thinks it uses, not not only those that are used. I would like to do a proper performance test (repeatable) identifying the areas that can be improved, but I also would like to investigate what it takes to implement full (or almost full) lazy loading in terms of speed and memory impact.

Would also like to take the cache improvements from Klas into this basic research, and based on the outcome we can see what could be changed in the code base.

[Andrew Eddie]

Following up, anyone been able to establish any baseline no-load tests yet?

For reference a no-load test would be done by setting an empty
template index.php and setting up a dummy component that does
absolutely nothing in both 1.5 and 1.6. The test should be done using
ab (Apache Bench) or similar.

Then I would progressively add more to the template to see the
relative effect of more code being executed. When doing full-load
tests you must ensure the data on both the 1.5 and 1.6 sites are
exactly the same (in so much as that is possible). There is no point
testing the default data from 1.5 vs the default data from 1.6 because
it's different and won't give any meaningful results.

Also, when giving test results alway include your system
specification, configuration setup and command-line options for ab.
SEF and non-SEF cases should be tested as well. Debug settings should
all be turned of to do timing runs. Finally, close as many
applications as possible while running tests (desktop apps, IM
clients, etc) as these can slightly skew the results.

Thanks in advance for those willing to help in this area.

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer