2.2.0-pl2: High CPU in Manager (seems higher than was on 2.1.x)

Greetings,

Am a veteran Evo user ('bout 3 dozen client installs). Have briefly tested Revo in the 2.1.x phase, but with 2.2.0 out, feel now is time to give it a serious tire-kicking.

Bad news, though is that in a shared-hosting environment where I've never had a single problem with Evo, nor (as I remember) with 2.1, the manager in 2.2 is really CPU-intensive (reported to me by host's tech support), to the point that the host is "throttling" me.

Just re-installed fresh (traditional) 2.2.0-pl. Have made zero changes other than to edit the home page. Just viewing the dashboard or opening the home page for edit seems to be enough to run the CPU use high enough to have the host throttle my use quite a bit.

I've not encountered this level of throttling before with this host, even when running Magento (shop. cart); a notorious resource hog. Contact with host tech support confirmed that it was the PHP process consuming the CPU.

Hoping there's a setting change I can make to MODX that'll overcome this. Have played around with various combinations of changes to compress_css, compress_js & compress_js_groups; no obvious difference.

Hosting Particulars

Bluehost
PHP version: 5.2.17 (with Suhosin)
MySQL server version: 5.1.60-community-log
MySQL client version: 5.1.59

Client Particulars (if it makes a difference?)

No real change in host throttling, regardless of browser / client. Have used Win-XP, Win-Vista, in combinations with Firefox 9 and current Chrome.

NOTE: I really don't want to traffic in "this host is better than that host..." discussions, and truly hope there's a setting change I can make that'll help out. I've been very happy with this host in dozens of sites, and would prefer not to change.

For that matter, neither do I want to move away from MODX. I've used, and been forced to use a variety of other CMS's and nothing else compares. Revo just makes it better.

Can you post your server environment as I have never experienced this sort of behavior, also what are your settings for css and javascript compression ?

Paulp,

Thanks for any thoughts you may have.

Server Environment

PHP/MySQL in orig. post
Architecture: x86_64
OS: Linux 2.6.32-46.1.BHsmp
Web: Apache 2.2.21
If other environ. info desired, please let me know what.

Compression

Have played around with various combinations of changes (on / off) to compress_css, compress_js & compress_js_groups; no obvious difference.

More info and a light -- sorry -- bump. Hopefully someone sees and has ideas. I'm happy to dig in and report on anything if additional ideas for research are offered.

See thread for full details. but the basic issue here is high CPU on manager activities on a fresh-install, vanilla Revo install with nothing else installed. The high CPU is enough for the host to "throttle" the account's CPU access in response to manager actions. Slowdowns happen on pretty much any manager action.

The only other application I've installed on this hosting provider that causes throttling is Magento - a known resource hog. Evo and other software I've used don't ever do it so It doesn't feel like the host is being unreasonable.

I'm hoping there's a Revo. config alteration that'll help.

I've experimented with turning manager CSS & JS compression on and off, and although I can't get exact numbers, I'm definitely seeing less of the host throttling the site for high CPU use when compression is disabled. Still there, but about half a often.

That seems to make sense, and is certainly acceptable when the (Google minifier?) compression code is running on first manager access, but isn't the output of that cached? I.e. once compressed subsequent Manager hits should be getting cached compressed CSS/JS?

I really want to move to Revo for production sites, but this manager slowdown is bugging me - I don't want content maintainers to be impaired.

BTW -- I ran a load test with up to 50 simultaneous clients at the public side of the same vanilla install site, and the host never throttled, nor did the performance of the site change as the test ramped up from one client to 50. I believe that qualifies for "great work by the site cache!" commentary.