In the admin however the performance of 3.4 is considerably better than in 3.3.6

Install Brochure Data and enable Debug System

Admin tests

Memory

3.3.6

10 MB (10,482,416 Bytes)

3.4 Beta 2

10.54 MB (11,057,040 Bytes)

DB Queries

3.3.6

25 Queries Logged 81.5 ms

3.4 Beta 2

24 Queries Logged 49.7 ms

Profile Information

3.3.6

Database queries total: 81.5 ms

3.4 Beta 2

Database queries total: 49.7 ms

I might be finding something unrelated but one obvious change in the debug output of the sites is that in J3.4 we have 5 Duplicate queries found

SELECT rules
FROM gal80_assets

WHERE id = '1'

Another big difference between the sites is with the 2nd query

Joomla 3.3.6

Joomla 3.4

In fact a lot of queries take much longer so I am going to stop posting them and guessing at the issues and just leave it that we have a serious issue with performance degraded with 3.4

I can confirm the issue in general, my numbers are different, some differences can be explained because I have a different environment some not

The debug output is a bit different: 3.4-beta2 show 0 as total queries and 3.3.6. doesn't show a number for duplicates

Were you using the same sample data set?

I raised a separate issue for the count of queries

Brochure data as you said and I used the home page

snap

On 7 February 2015 at 15:05, Robert Deutz notifications@github.com wrote:

Brochure data as you said and I used the home page

—
Reply to this email directly or view it on GitHub
#5996 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

This is a test run with

• 250,000 articles in single view (about 10 seconds for the DB-QUERY)
• pagination enabled (about 4.5 seconds for the DB-QUERY)
• article counting enabled (DB-QUERY takes about 45.6 seconds !!)

content table is about 1.1 GBytes
on SSD with sustained rate on big transfers 250 MB/second

(repeated runs results remaining the same)
-- 61.37 seconds for J3.3.6
-- 60.18 seconds for J3.4 beta2

there seems to be no scalability problem of J3.4 Beta 2 compared to J3.3.6
but i have not tested

• big category table e.g. 2000 categories
• big user table e.g. 50,000 users
• or big tags table

The 2nd query @brianteeman noted is a query changed in this commit and this line: 94f3fbe#diff-a9ca78ba0a2d4e122abeb2b5a906dc55L410 by @Hackwar. Hannes may be able to explain why the element filter has been taken off.

The filter was taken off because the internal cache would load each component only on request previously; now only the first call to JComponentHelper::load() queries the database and loads all of the components into its memory.

As @mbabker said. This should actually increase performance. In any case, we might be able to improve here a tiny bit by adding an index on the type column. There currently is none, so from my limited DBA knowledge, we should gain a little bit by adding a simple index on that one.

If you want to improve performance, re-evaluate adding #5963 and #5140 to 3.4.0. That should give a small boost and remove a query or two.

In any case, I can say with confidence that that query change is not the reason for a possible performance drop.

So what is?!

SQL Server cpu usage
SQL Server disk IO
SQL Server cache hit ratio
SQL Server memory utilization

also PHP memory usage makes difference

even 1 different query,
can effect the performance of other queries that have not changed

we are talking of milliseconds, e.g. 1 extra disk IO operation

i don't say not optimize and look into this, of course it should be done, i am sure you will find it

just it is not too serious if it does not cause a scalability problem

Just wondering how often we call JComponentHelper::load() should be that we call it for more then one component the exception?

We load at least twice per pageload, maybe even more. At least once to get the default language from com_languages and once for the actual component to load. It might also be loaded for some media manager configurations or the configuration of a module that depends on a component.

BTW: One reason for additional queries would be #5276, which would be removed again with #5140. Calling the helper with the correct parameters forces the language lookup array to be populated and thus runs an additional query. #5140 drops all that code and thus removes at least the potentially 4 additional queries in our core components.

is there a way to test and see if it is #5276 causing the issue. We really can NOT release when it is twice as slow as previous versions. Hardly a great message for the marketing working group to promote

#5276 fixes bugs with wrong language associations, so they are needed. But as I said, #5140 fixes that again. And no, #5276 is not broken then. That PR fixes bugs in how those methods are called and #5140 fixes a structural bug in that method itself.

I am not blaming any PR I just want to be able to find out what is causing
the performance issue so that we can resolve it. We can NOT release 3.4
while it is twice as slow as 3.3

On 8 February 2015 at 17:05, Hannes Papenberg notifications@github.com
wrote:

#5276 #5276 fixes bugs with
wrong language associations, so they are needed. But as I said, #5140
#5140 fixes that again. And
no, #5276 #5276 is not broken
then. That PR fixes bugs in how those methods are called and #5140
#5140 fixes a structural bug
in that method itself.

—
Reply to this email directly or view it on GitHub
#5996 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

I can not confirm that it is vastly slower than 3.3. My dev installation behaves pretty identical to 3.3. I can only tell you where I changed something that might have a detrimental effect and how that could be fixed again.

When talking of speed, in computer science you always speak of large enough N, it is the first things that anyone learns, to rule out effects of algorithm shallow cost and of effects of 1st level cpu cache, etc

Now, if you are going to compare speed, and you have 10 factors, and you want to speak of 1 of them, then maybe if the other 9 are identical, then maybe you can compare

a small example for our case (3.3.6 and 3.3.4 beta2),
assuming that you are running the web-server and the SQL server in the same machine, a larger memory usage of the web-server (PHP, etc) will effect the cache hit ratio of other processes in the CPU cache(s), thus it will effect the SQL server process, more or less depending on the CPU

and 3.3.6 and 3.3.4 do not have the same memory usage !

furthermore, since the word "vastly" was mentioned in this thread
lets not forget that just 1 byte of extra data, can make a program run 50 times slower

if you have N time, optimize for very large / medium sizes, if you have 2N time, optimized for small, if you have 3N time to spare then optimize for small data sets

I DONT SAY THAT there are no bad queries, i see the same results as Brian, and probably we can do some optimizations without effecting the desired behaviour

but i argue performance difference is insignificant even in small/medium size websites due to site's size not being very small and due to other page costs (e.g. examples 0.51 seconds and 0.54 seconds),
further as said above it is not simple to assign blame, of course again i don't say not to optimize the queries and i don't say not to look into this

finally, since it seems, i was ignored in this thread, i will not make any more posts, and if someone was annoyed by postings, then please forgive me, also forgive my ignorance, it is due to my limited knowledge in computer science,

i wish i could have more time to contribute, because i don't want to be like a fat guy (and i am fat at periods) in a football match speaking of footballers are not running fast enough

thank you for your works

My concern is that of someone doing a comparison of 3.3 AND 3.4. The first
thing they see when comparing identical setups is that it is slower. That's
currently a fact that cannot be ignored.

Yes, you are right

if someone will only look at the queries in a very small website, then the performance difference in SQL queries is considerable, and he/she could make such a claim

Sadly that is exactly what happens and unlike yourself they won't test with
huge amounts of data.

Unscientific testing. Started with a fresh 3.3.6 install from the package, then updated the same site to the 3.4.0 Beta 2 package. Tests are with debug mode enabled and error reporting set at development.

Admin Control Panel (first request after login):

Homepage:

Same tests with current staging (commit 33e1d0e) via my local git clone:

Admin Control Panel (first request after login):

Homepage:

By the numbers, yes there is a noticeable change. It's entirely possible the referenced PRs here are the cause of it. It's also possible those PRs are geared toward larger sites (say something the size of joomla.org or akeebabackup.com) and will help performance on larger sites which makes a negative impact on a smaller site. Hard to really gauge without doing more performance tests against sites of varying sizes.

i've compared the 3.3.6 stable (fresh) with 3.4.0 beta 2 (fresh) on mysql both with brochure data only,
tested the homepage with mysqlslap and i've noticed that :
the average number of seconds to run all queries:

336 => 0.8 seconds
3402 => 1.0 seconds

so 20% less performance +
the 340 beta 2 runs 5 queries more than 336
i'm going to compare a more "medium" large size

but surely these results are not encouraging

0.8 seconds and 1.0 seconds ?
for --SQL Queries-- with ... "brochure data only" ??

that is strange, both results are very slow

I've runned without any cache on a slow system , but don't look at time in absolute think in relative terms

Apache bench (page load times),

• Homepage with brochure data,
• Mysql cache ON,
• Joomla cahing OFF

J3.4 beta2 / J3.3.6
500 runs, 1 concurrent connections : 18% slower
500 runs, 6 concurrent connections : 26% slower
500 runs, 20 concurrent connections : 25% slower
500 runs, 100 concurrent connections : 25% slower

Thanks for the tests
On 9 Feb 2015 17:42, "Georgios Papadakis" notifications@github.com wrote:

Apache bench (page load times),

• Homepage with brochure data,
• Mysql cache ON,
• Joomla cahing OFF

J3.4 beta2 / J3.3.6
500 runs, 1 concurrent connections : 18% slower
500 runs, 6 concurrent connections : 26% slower
500 runs, 20 concurrent connections : 25% slower
500 runs, 100 concurrent connections : 25% slower

—
Reply to this email directly or view it on GitHub
#5996 (comment).

I am afraid, problem is a little worst,
because SQL queries are the smaller part of the issue,

the SQL queries in item view are indeed 15%-20%,
but ... still under server load they are relatively small !!

performance degrade due to SQL seems to be 1%

Overloaded server (100 concurent connections, and similar for 10+ concurrent connectopns)
J3.4.x: (total) 15440.0 ms (SQL about: 200 ms)
J3.3.6: (total) 12350.0 ms (SQL about: 160 ms)

Apache utilization of (CPUs): 75%
MySQL server utilization of (CPUs): 1-5%

Performance difference due to SQL ... 1%

So maybe my initial speculation that PHP execution is also effecting SQL server performance maybe correct, so we should not only look at the queries, but also at PHP code , and at extra memory usage

maybe it is worth it / needed and this performance change can not be avoided

the interesting part would be to know where the loss is. having the debug output of 3.3 and 3.4 would be beneficial to know how long between onAfterinitialise, onAfterRoute, onAfterDispatch, etc. With that knowledge we could see if this is due to some changes in the component, in the router or the application initialisation or if it is an issue in a module that we load on each page.

Here you go.

3.3.6:

3.4.0-beta2:

Looking at those numbers, the major difference seems to be somewhere in our module rendering code... The component mostly behaves identical, at least based on the slight changes in routing that we have. It is the modules where we have a negative impact with performance decrease of 10 times slower than before.

Modules Front end editing?

In theory that should only matter on an authenticated request (both tests were unauthenticated). From that PR specifically, the only place I can see that would affect all modules is https://github.com/joomla/joomla-cms/pull/2521/files#diff-22ab4a7886db6d75e41b55aef610643b and that doesn't seem like it would be the culprit at a glance. Unless something else changed in the ACL checking code too.

It would be interesting to add a check for $user->guest in line 47 of that thingy there. It would stop the checks a lot earlier. I also see that there are A LOT more different ACL checks now. Before there was just one check that most of the time quickly failed, while this new check might take a lot longer to properly calculate and even force additional queries to the DB. Just a guess though.

Just wrapping that if statement in a !$user->guest check is making a huge difference for me locally. No other tweaks made.

created a PR for that in #6032. Please test.

That PR however does not explain all negative performance that we see. It also does not solve the issue when a user is logged in. Frontend editing is REALLY bad here.

Brochure data home page with all modules disabled

336

34b2

So it is indeed in the modules. I could even say that we have a tiny performance improvement without the modules from 3,3 to 3.4, although that will most likely be below the measuring tolerance.

I don't like that frontend editing for modules is enabled by default. As we can see, it is quite a performance issue. Could we set this to not enabled by default?

3.4beta2 brochure data with modules and default of front end modules on (note duplicates)

3.4beta2 brochure data with modules and front end modules OFF

Please see #6034 for another performance boost.

Another performance improvement: #5952

And I see this GSOC project for improving Joomla DB optimization not get into the door? Would this not solve part of this performance problem(s)?

#4107
#4112
#4115

Just an opinion, ACL checks for unlogged users should be avoided/removed or cached regardless of caching settings, myself i have decided to cache them regardless of Joomla caching settings for those i could not remove

my 5 cent:
query duplication comes from asset.php on this block, it can be simple fixed by using static variable, something like:

// Get the root even if the asset is not found and in recursive mode
        if (empty($result))
        {
            static $root = null;
            if(!$root)
            {
                $db = JFactory::getDbo();
                $assets = JTable::getInstance('Asset', 'JTable', array('dbo' => $db));
                $rootId = $assets->getRootId();
                var_dump($result, $rootId);
                $query->clear()
                    ->select('rules')
                    ->from('#__assets')
                    ->where('id = ' . $db->quote($rootId));
                $db->setQuery($query);
                $result = $db->loadResult();
                $result = array($result);
                $root = $result;
            }
            else
            {
                $result = $root;
            }
        }

then,
as @Hackwar @mbabker already mentioned, this contsruction is useles for guest users, so addiding !$user->guest in this if() block will help a lot

who do pull request?

for non guest users,
there is access check by each module asset: com_modules.module.83, com_modules.module.16, com_modules.module.17 and so one...
more modules on the page - more DB requests ....
with 100 modules on the page it will be a very bad thing

maybe we can somehow load the asset tree for com_modules.module and then do access check using already loaded tree ... but this I not very imagine how to do

@Fedik I already did a PR in #6032 for the if(). I also looked into the JAccess thing some time ago and there are issues there that made it difficult to simply replace it with a static. Please don't ask me what it was, it's been about 2 years ago that I looked through that. However, setting that feature to not enabled by default, would get us around most of those access checks.

Last but not least, I question the reasons for allowing people to be able to select certain modules to be editable and others not. I don't see a reason for that. Could someone tell me a legitimate use-case where a user should be able to edit one module but not the others?

To answer your last part and assuming I understand the question and
scenario correctly.

I build a web site using a mix of custom html and "other" modules. The
"other" modules are structural and I dont want them to be edited by anyone
other than a super admin. The custom html modules are used for content and
I do want them to be edited by anyone who has access to create content.

On 10 February 2015 at 10:00, Hannes Papenberg notifications@github.com
wrote:

@Fedik https://github.com/Fedik I already did a PR in #6032
#6032 for the if(). I also
looked into the JAccess thing some time ago and there are issues there that
made it difficult to simply replace it with a static. Please don't ask me
what it was, it's been about 2 years ago that I looked through that.
However, setting that feature to not enabled by default, would get us
around most of those access checks.

Last but not least, I question the reasons for allowing people to be able
to select certain modules to be editable and others not. I don't see a
reason for that. Could someone tell me a legitimate use-case where a user
should be able to edit one module but not the others?

—
Reply to this email directly or view it on GitHub
#5996 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

@Hackwar sorry, I missed it
but it only for guest, for non guest users there still will be a query duplication because thing in asset.php

@brianteeman I would rather see us provide a module that displays a single article in a module position and where you can then edit the article, than to add this feature like this. As we see, this has quite an impact on performance and it means lots and lots and lots of checks for modules where I never want people to be able to edit them. For example the logo of my site in quite a lot of templates, etc. So if you want to be able to allow people to edit just a few specific module positions, it would be better from my perspective to provide such a single-article-module as a replacement for mod_custom in those cases, than to have these expensive access checks each time and for every module.

@brianteeman I think Hannes question might have a legitimate answer in your previous comment, but I wouldn’t do it that way. Eg use one of the many news show modules, select the article you want and give access to the users to edit that article is much easier than give them access to mess around with modules. @Hackwar Exactly that!

I think we will have to agree to disagree on the usefulness of this feature

@Hackwar @dgt41 you thinking in wrong direction
remove/disable some feature it not real solution,
real solution is make asset check more efficient

in theory (I not tested, but need check), such thing also can happen if you have 100 articles on the one page and do check for each whether user have access to edit each or not

@brianteeman I'm not disagreeing with you that this feature is usefull to some people. However considering the difference between having to do one check for all modules and doing a check for every module on the page each time it loads, I'd rather take the first option. You brought up that the performance of 3.4 is noticeably worse than 3.3 and I'm telling you that it is this check that we are doing, which breaks the whole thing. We can improve that for guest users, but that still makes 3.4 ~20% slower for authenticated users.

Joomla has a performance problem. There was a time during 1.6 development, when we got performance improved by about 40% compared to 1.5, but in the meantime, that gain has been more than eaten up by all the big and small features that were added, often enough with total neglect regarding the performance. There are 3 things that we have to work on in the next 3 years for Joomla and none of those is any additional features. We need to improve useability for the administrators, we have to provide better MVC classes to the developers and we need to improve performance. I personally don't want to see any new features in Joomla that don't fall into one of these categories and while you might say "This improves useability for users" I would disagree, because I only got questions from my customers why there are these additional icons on their page and if that is present for everybody.

@Fedik There is only so much that you can do. We are caching the access checks in the users session, which means that most of the results from those checks already come from a cache and don't require a call to the database. At the same time, the data that can be stored in the session is limited and thus we can't load the whole permission tree into the session. Access checks are expensive, so we should limit them to the right amount. And there is little that you can do to make those checks less expensive.
Yes, we have a similar situation for articles, but the ratio articles/modules per page is a lot smaller than 1 in 99% of the cases. That means that checking each module is vastly more expensive than checking the articles. If you are on your homepage and it has 10 modules and 5 articles, you do 10 checks for the modules and 5 for the articles. If you are in the single article view, you do one check for the article, but still 10 checks for the modules. If you are on a contact page, you do 0 checks, but still 10 for the modules.
Use those checks wisely and my opinion here is, that this is not using them wisely.

Actually, I would prefer if this feature was implemented by a plugin. You would not need a switch in global configuration, but could simply enable/disable the plugin. The plugin could load an alternative modules renderer and the 95% of all our users that don't need this, wouldn't be bothered by it. The way it is now, quite a lot of people have this alredy enabled, simply because it is set to enabled by default, instead of giving the user the choice in a post install message.

I've provided a PR to set this to not enabled by default in #6041

Just for reference: This feature blows up the rendering method from 8 lines (including blank lines) to 23 lines of code.

Lets clear up a few things

Front end module editing was introduced in 3.2
ACL for modules was introduced in 3.2
The text strings for Front end module editing have not changed
The default enable status of Front end module editing has not changed

The performance problem that this issue was created for was for the change from 3.3.6 to 3.4

This performance problem has been resolved by a PR fm Hannes

Any other issue that you have with the Front end module editing is off topic of this issue and should be addressed elsewhere

So your response to a feature that is really bad in terms of performance is "You fixed the part that was absolutely killing the system, but please shut up about the rest that is making the system crawl along at a snail-like pace"? Lets put a bandaid on it and everything will be fine.

The feature has been present in some form since 3.2. Ripping it out completely isn't an option now. One of the issues that came up with the updated version is fixed with your PR, let's get it merged and focus on other concerns as separate pulls.

+10

On 10 February 2015 at 15:05, Michael Babker notifications@github.com
wrote:

The feature has been present in some form since 3.2. Ripping it out
completely isn't an option now. One of the issues that came up with the
updated version is fixed with your PR, let's get it merged and focus on
other concerns as separate pulls.

—
Reply to this email directly or view it on GitHub
#5996 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

Can we close this Issue then? Or is there still a noteable performance issue with 3.4.0?

Which is exactly what I'm doing. The first fix is #6032, the other is #6041. Other performance improvements can be achieved by applying #5140, #6034 and (althouh just a tiny bit) by #6044.

There are still issues when a user is authenticated and has the frontend module editing feature enabled. The PRs @Hackwar referenced help in different scenarios but I don't see anything yet that can deal with the ACL checks when module editing is enabled on the frontend and a user is authenticated.

Ah I see.

is it not the same with article editing?

In theory it would be the same on any list page in the admin since each row makes a check (depending on the component, several checks for edit and edit state)

please check another try #6046

Please see another big performance improvement here: #6053

In general, we now have the following PRs that would provide a boost in terms of performance:
#5140
#5950
#5952
#6032
#6034
#6041
#6044
#6053

Each of these could be part of J3.4.

So... any news on this stuff? I mean, #6032 is no big change, it got several good tests, etc. The release of 3.4 RC is coming closer and closer and right now it's been 7 days since that proposal was made and 5 days since the third successfull test in a row was done.

Its time for leadership to step up and ask for priority of what should be tested/merged for Joomla 3.4? You can at least ask for that and agree with Hannes that this should be one of the priority task for coming J 3.4 or what you think?

Closed as the commits have been merged