?
avatar ericsson77
ericsson77
26 Feb 2015

Steps to reproduce the issue

  1. Install Joomla 3.4
  2. Get MySQLi/MySQL up and running
  3. Debug some simple sites/empty templates. #### Expected result Somewhat reasonable queries

Actual result

queries

System information (as much as possible)

Fresh Joomla 3.4 setup, only site currently hosted.

Additional comments

I am not a developer deeply involved in the inner workings of MySQL or how Joomla process queries but when a development site, with little to no content, takes well over 1 minute per page to load, then something is wrong :)

I re-installed 3.4 twice and tried with a fresh start, still the same thing and also contacted my host provider to confirm that the servers were running as they should. Replacing the $query->where('(a.publish_up >= DATE_SUB(NOW(), INTERVAL 1 YEAR))'); code as someone suggested did nothing to speed things up. Don't know if this is a specific bug for 3.4 or not but with 3.3 everything worked fine and speedy.

avatar ericsson77 ericsson77 - open - 26 Feb 2015
avatar Fedik
Fedik - comment - 26 Feb 2015

On first look it something on component level, on the page where you made screenshot,
in real can be anything...

Current info not enough, I think would be good to see the query debug, and a bit more detailed description what you did :wink:

avatar mbabker
mbabker - comment - 26 Feb 2015

In terms of modules, the RocketTheme menu is somewhat slow and that component needs some performance attention (the dispatch metric would also include any plugins running in the component). Knowing what extensions are in use here would help too. If it's a core component, an idea about the size of the data on the site could help also.

avatar ggppdk
ggppdk - comment - 26 Feb 2015

Probably it is that component code and modules are using heavily
--> 1 or more Joomla API function which has/have degraded performance in J3.4 ?

-- we cannot know without running XDEBUG or ZEND Studio on the website, everything else is guessing

avatar brianteeman
brianteeman - comment - 27 Feb 2015

Please retest without the roknav menu and report back. That way you can test if @mbabker is correct (fairly sure he is) but then you will be able to see for yourself


This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/6201.
avatar brianteeman brianteeman - change - 27 Feb 2015
Status New Information Required
Build 3.3 3.4
avatar brianteeman brianteeman - change - 27 Feb 2015
Labels Added: ?
avatar emeyer444
emeyer444 - comment - 17 Mar 2015

I did have a problem with this. What I did was manually:

  • turn off mootools scripts
  • turn off jquery scripts
  • turn off bootrap
  • disable chosen.css manually because it still loads anyway
  • create template overrides for all components and modules and remove all tooltips
  • use echo to stdout or string catentation rather than pushing and popping /<php ?/>
  • replace all language string searches with hardcoded text to stop enormous searches (at least 25% improvement in server response time
  • remove all whitespace from generated code
  • perform compression on scripts and css files with htaccess directives, disable joomla gzip compression
  • rewrote windowing software in a javascript routine less than 8KB total for front end that does almost everything mootools, jquery, and bootrap did.
  • removed >200 unused css classes and IDs
  • replaced 1500 css rules with 100 that do much the same thing.
  • added smaller version of jquery to module at end of pages in async and defer mode where it wasnt being used so it would preload for login and registration. Disalbed this module on com_users component
  • added same version of jquery to com_user component
  • persuaded isp vendor to support fastcgi

In total, this reduced the libraries needed for most pages from 300KB to 4KB, and css from 80KB to 12KB,

from Got time from 8 seconds load for uncached page to 1 second for most of the site. Sadly in overconfidence I deleted the 4KB tablesort script and have to load 100KB of mootools for client-side table-sort from some prehistoric day I fixed that but Joomla dev wasnt interested, so I stupidly didnt keep it.

avatar emeyer444
emeyer444 - comment - 17 Mar 2015

Oh, that being said, almost all the performance issues could be fixed with template overrides,and the core is much better.And It only took a month to do.

avatar dgt41
dgt41 - comment - 18 Mar 2015

rewrote windowing software in a javascript routine less than 8KB total for front end that does almost everything mootools, jquery, and bootrap did.

@emeyer444 would you share that?

avatar brianteeman brianteeman - change - 22 Apr 2015
Status Information Required Closed
Closed_Date 0000-00-00 00:00:00 2015-04-22 23:54:45
Closed_By brianteeman

Add a Comment

Login with GitHub to post a comment