Very slow performance after 1.4 - 1.11 upgrade

[bussemac]

By way of introduction, I don't really know much about CMSMS. I was called on to fix a client's site after it tanked with php Deprecated (and Warning) messages after GoDaddy advised her to upgrade her site from PHP 5.2 to PHP 5.3.

Right away I suppressed the errors using php.ini but then I started the upgrade process. I went from 1.4 to 1.5, to 1.6, etc up to 1.11 and finally to 1.11.1, figuring that 7 versions out of date was bound to cause problems at some future date.

The site is VERY slow now, even though I've turned on what I can find for caching.

I've attached a debug for the home page.

Modules that are installed according to the admin page:

Name Version Status
Album 0.9.3 Installed
CMSMailer 5.2.1 Installed
CMSPrinting 1.0.3 Installed
FileManager 1.4.0 Installed
Has Dependents (MicroTiny)
MenuManager 1.8.3 Installed
MicroTiny 1.2.3 Installed
ModuleManager 1.5.5 Installed
News 2.12.8 Installed
Printing 1.1.1 Installed
Search 1.7.7 Installed
ThemeManager 1.1.7 Installed
TinyMCE 2.8.0 Installed
nuSOAP 1.0.1

10 seconds to render the home page is just bad. What can I be looking at here to get this back to a more reasonable loading time? I have a backup prior at 1.4 but since I did all the upgrades back to back to back to back, I didn't make another backup at any point, and I don't remember the site getting quite this slow until the 1.11.1 (as in, I recall it being OK at 1.11, but that might be faulty memory).

I have plenty of PHP experience, but without knowing my way around this CMS system, I'm not sure where to start looking for more speed. Thanks in advance for the help!

[calguy1000]

Since it's godaddy (my personal least favorite host). I will bet its primarily because of the non-local database.

The debug.txt file shows that the first few seconds are spent just loading the data from the database. I'll show you some of the output from the debug.txt file you sent, and some corresponding source code.

Debug output:

Code: Select all

Debug: (6.5999999999997E-5) - (usage: 1020360) - (peak: 1043284)
done loading required files
Debug: (0.817449) - (usage: 1021052) - (peak: 1064544)
loading adodb
Debug: (0.840251) - (usage: 1098904) - (peak: 1127308)
loading page functions
Debug: (0.857362) - (usage: 1226624) - (peak: 1289996)
loading content functions

Corresponding source code:

Code: Select all

debug_buffer('loading adodb');
require(cms_join_path($dirname,'lib','adodb.functions.php'));
load_adodb();
debug_buffer('loading page functions');
require_once(cms_join_path($dirname,'lib','page.functions.php'));
debug_buffer('loading content functions')

This means that loading the first few files was very very quick. But that just connecting to the database took ~0.81 seconds. A further 0.4 seconds was taken just including two files. Once you extrapolate that to the amount of database work that CMSMS does to build a navigation, load modules, load content and render a page you can easily see why that host would take 10 seconds.

We know that smarty3 is slower than smarty2 in compiling but your host is slow just in connecting to the database and in including some files.

As a comparison... I cleared the cache and enabled debug mode and copied the following lines from my installation (running on a virtual machine from my laptop).

Code: Select all

Debug: (2.1999999999966E-5) - (usage: 1056652) - (peak: 1061728)
done loading required files
Debug: (0.007277) - (usage: 1057628) - (peak: 1101068)
loading adodb
Debug: (0.0084339999999999) - (usage: 1146252) - (peak: 1168612)
loading page functions
Debug: (0.010014) - (usage: 1286872) - (peak: 1369392)
loading content functions

Notice that I'm at 0.01 seconds for the same functionality that is taking your host 0.85 seconds. My personal recommendation is to complain to GoDaddy (good luck with that). Or find a new host.

[bussemac]

Yeah, not my first choice either. I just got this thrown in my lap on Saturday and I'm still trying to get to the bottom of it all.

What am I looking at here that's taking 2.2 seconds?

Debug: (3.052547) - (usage: 4271964) - (peak: 4296608)
Loading /home/content/s/o/l/solar1/html/lib/classes/class.CmsNls.php = 27592 bytes for an approximate total of 1895668
Debug: (5.241673) - (usage: 4398048) - (peak: 4423308)
Loading /home/content/s/o/l/solar1/html/lib/classes/class.CmsRoute.php = 26872 bytes for an approximate total of 1922540

[calguy1000]

Those debug statements are generated by the autoloader ...
Probably from within the constructor of the Album module, or in the SetParameters method (which is called from the Constructor).

Those two classes are interdependent and loaded closely to each other to attempt to determine the language requirements, and then load the appropriate language files.

There is not alot of logic going on in there (when you dig down to it). So I would suspect that the account you are working in resides on a very oversold host.... My install is at 0.05 seconds when loading those classes.

Code: Select all

Debug: (0.04585) - (usage: 4055480) - (peak: 4135068)
loading module Banners
Debug: (0.053233) - (usage: 4813412) - (peak: 4876248)
Loading /var/www/cms_dev/lib/classes/class.CMSModule.php = 449872 bytes for an approximate total of 2039168
Debug: (0.055261) - (usage: 5032052) - (peak: 5079080)
Loading /var/www/cms_dev/lib/classes/class.CmsNlsOperations.php = 65200 bytes for an approximate total of 2104368
Debug: (0.056316) - (usage: 5074924) - (peak: 5127008)
Loading /var/www/cms_dev/lib/classes/class.CmsNls.php = 31132 bytes for an approximate total of 2135500

I wouldn't expect similar numbers from a shared host... but I also would not expect 5 seconds just to reach that point.

I don't think it will buy you much, but in the system maintenance page of 1.11 there are a couple of buttons to optimize and repair tables. also, make sure you clear the cache again.

[bussemac]

Well either the host got less overloaded or something really improved after the optimize tables command. I don't have a fresh debug but eyeballing it I'd say it's pretty slick.

Thanks for the help!

[bussemac]

Bah, unsolved. I'm really starting to think it's the host. I had them enable SSH so I could do the upgrades without having to FTP 50000 files. Somehow that also required them to change my database host. I have no idea why that would be true, but who can really say what GoDaddy is thinking?

So I think I just got lucky and happened to be testing after 5 pm EDT yesterday, when all the east coast users suddenly stopped surfing other sites on the shared server.

What hosts are generally better for CMSMS (wait, let me guess: anything but GoDaddy? )? It's a really basic site, all of 10 pages, a couple pictures, some links, a PDF. So really we just need a host offering good (doesn't have to be excellent) performance for decent prices.

[bussemac]

FWIW, GoDaddy actually DID acknowledge that the server is under heavy load and they're "trying to fix it."

[stevehong]

By way of introduction, I don't really know much about CMSMS. I was called on to fix a client's site after it tanked with php Deprecated (and Warning) messages after GoDaddy advised her to upgrade her site from PHP 5.2 to PHP 5.3.

Right away I suppressed the errors using php.ini but then I started the upgrade process.

Bussemac or others, I had the same thing happen to some of my sites running old versions of CMSMS on GoDaddy recently. I'm a front end developer and not well versed in PHP. Would you be able to share how you fixed the error messages with the php.ini file? Is this an actual fix or is it just masking problems?

[bussemac]

By way of introduction, I don't really know much about CMSMS. I was called on to fix a client's site after it tanked with php Deprecated (and Warning) messages after GoDaddy advised her to upgrade her site from PHP 5.2 to PHP 5.3.

Right away I suppressed the errors using php.ini but then I started the upgrade process.

Bussemac or others, I had the same thing happen to some of my sites running old versions of CMSMS on GoDaddy recently. I'm a front end developer and not well versed in PHP. Would you be able to share how you fixed the error messages with the php.ini file? Is this an actual fix or is it just masking problems?

Create or edit the php.ini in your CMSMS root folder on your GoDaddy server.

If you already have a line

Code: Select all

error_reporting=XXXX

, edit it, else add it, so it looks like

Code: Select all

error_reporting=E_ERROR

That's my recommendation anyway -- that will show an error if there's a really serious error, and hide the rest. Most of the errors are related to functions which PHP is planning to remove in future versions (the 6.x line), and presumably the developers are working to update the code to use the alternative functions instead.