Saame MODX install/data/page running 4-5 times slower on different servers

It's been a while since I had to do this, so could someone refresh my memory as to what I should be looking for / at in order to get decent speed? I'm running Revo 2.2.0pl2 in this instance.

I have literally the same page/data etc loading in 4s on one server and 17-28(!)s on the live server. The core difference between them is that the live server is running PHP5 using .htaccess, as opposed to system-wide, if that makes any difference?

Dev server - PHP Version 5.2.17 MySql 5.163
Live server - PHP Version 5.2.17 MySql 5.157

The live server is parsing an additional php.ini file from the folder above, which I don't want it to do but don't know how to avoid.

Any pointers please? I manually moved the site over, so is there a config setting I might have missed, or something else I should do....

TIA [ed. note: odeclas last edited this post 14 years, 4 months ago.]

What do you mean, running PHP5 using .htaccess?

Sorry - I knew that was imprecise - the host has instructed me to use 'SetEnv DEFAULT_PHP_VERSION 5' in .htaccess to get PHP5 running. It's run as a CGI.

I'm going a bit nuts here. Plus the page rendering times are all over the place - all slow, but not consistent - 11, 13, 15, 27, 13 (I'm using the network tool on Safari Web Inspector - as you can tell I'm a bit of a n00b at all this).

I know the page itself could do with some optimising, but I'm completely confused by the massive performance discrepancy (and it's not the network either - the problem host serves html pages faster than the 'good' MODX host).

It sounds like a poorly performing PHP configuration to be honest. Can you share more details about how this is run via CGI? We might be able to shed some light on it with more info...

Hello,

A properly configured server shouldn't have any problems rendering a page in under 11 seconds, so I would agree with Jason, please share some details on your hosting environment.

I would also be slightly concerned about any hosting company that is instructing you to use .htaccess to enable PHP5 support. There is NO valid reason to have php4 running on any server as it's a security risk. I can understand using .htaccess to get a specific version (ex: 5.3 vs 5.2, or 5.4), but not to get PHP5. If the server is using CGI instead of FCGI that would explain the performance issues.

My hands are a bit tied to be honest. The client has a package that gives them three domains on one instance. The 'main' domain runs PHP4, so I can't just switch the account to PHP5.

This is the first migration I've done where I've zipped files and database and followed the RTFM steps to do a migration. I had done it once, checked it sort of worked (other than FURLs) and then I simply dropped and restored a db backup when it was time to go live.

I'll try and get some more details on the CGI aspect, but I just want to rule out MODX config issues if there's something I should have been looking out for (tiny example, Articles uses Extension Packages setting which needs updating, and isn't explicitly in RTFM).

I'm thinking it might be phpThumb-related, but there are some other odd issues.

A page without a thumbnail, that just retrieves a resource and does one Wayfinder call (there are other things happening too, but you get the idea) renders in ~4s on this new server. On my dev server (different host) it renders in 1s.

A page with 1-N thumbnails will take at least 9s to render (it doesn't really seem to matter whether it's a product page with one thumbnail or a listing page with 9 thumbnails).

Frustrated. Mainly because I simply don't have a clue where I should be looking. The MODX log is empty, the site works. It's just stupidly slow compared to what I know it can run.

I've used the Executioner snippet to try and assess where the damage is occurring. I have a getResources call which uses phpthumbof output modifiers and takes over 10s to execute on the 'bad' server and 2s on the 'good' server.

Regardless of whether I've optimised the script or not, that's not a good sign is it? The host support is wittering on about loopback calls not being allowed and not generally being much help.

10+ professional hours lost already. On what should be a non-issue.

You coul use firebug to see if its taking the server so long. if its a certain script or if its slow in general.