While optimizing a large Joomla website this morning (the website had around 100,000 pages), we noticed that the website was considerably slower for logged-in users than for the general public. Most pages, on that particular website, were loading (after our optimization) in 0.2 to 0.3 seconds for visitors, but these same pages were taking nearly 20 seconds each to fully load for logged-in users (including super users). The pages that were mostly affected were Category List views. Hmmm!
In order to unveil the secrets behind the slowness, we printed all the queries that were executed to generate a page for both logged-in users and guests. To our surprise, we saw that there were many additional queries that were being run only for logged in users, and all of these queries had something to do with the #__assets table.
So, what is the #__assets table?
The #__assets table is one of Joomla’s 1.6+ (e.g. all versions above 1.6, including 1.7, 2.5, and 3.x) worst ideas. It is used to keep information about all the installed/added extensions/content items on the Joomla website. This information tells Joomla the following information: who is the parent for each of these extensions/content items and which users have permissions on these extensions/content items.
OK, now what were these queries and what is their purpose?
These queries, as stated above, were mainly querying the #__assets. There were many of them and they were not always the same. Some of them were quite complex and inefficient – that inefficiency is only evident when you have many rows in the #__assets table – which is the case when you have 10,000+ articles on your Joomla website (each article is represented by an entry in the #__assets table). The inefficiency was that each of these complex queries had a LEFT JOIN on the #__assets table itself, so the query was something like:
SELECT b.rules FROM #__assets AS a, b.id, b.rules, b.lft WHERE (a.name = ' value' OR a.parent_id=0) LEFT JOIN #__assets AS b ON b.lft <= a.lft AND b.rgt >= a.rgt ORDER BY b.lft
If you care to know, the above query is used to calculate the permissions that the logged in user has on the displayed content (e.g. maybe the user shouldn’t see that content, or maybe the user should be able to edit that content, etc…). While this functionality is helpful for some websites with complex user permissions, it is useless and represents a huge overhead for large Joomla websites.
So, what did we do to solve the problem?
Unfortunately, we had to modify Joomla’s core to fix the problem. There was no other solution since the problem was actually built-in in Joomla (we never used the word built-in in a negative context before – well, there’s always a first for everything).
Once we did the modification, the site ran very smoothly even with logged-in users.
Is there another solution?
Migrating your Joomla content to K2 can also solve the problem – since K2 is a much better and efficient platform than Joomla’s core content management system (Unlike Joomla’s core, K2 doesn’t use the #__assets table for displaying any of its content).
We understand that Joomla can sometimes be a bit disappointing performance-wise, especially for large websites. We can fix that for you – just contact us and rest assured that your Joomla website will run at a blazing speed once we’re done with it – oh, and we won’t charge you much!
Have a related company website that is experiencing slowness due to lots of logged in users. I’m a bit tentative though to implement a core hack on such a large site. Can you tell me more?
Hi Steve,
Typically, a core modification is necessary when the problem is within Joomla. However, keep in mind that before modifying the core, we try to optimize the database as explained here. If the results are very positive, then we don’t change anything in the Joomla core.