[solved] admin - very slow

[calguy1000]

Can you turn debug mode on... edit a page, and copy/paste the info from 'End Loading Hierarchy Manager' to 'end get all content'

Here's mine (I only have about 10 active pages at the moment).

Code: Select all

Debug display of 'End Loading Hierarchy Manager':(0.31263) - (usage: 14121048) - (peak: 14255720)
Debug: (0.313282) - (usage: 14126580) - (peak: 14255720) (mysqli): SELECT * FROM cms_content FORCE INDEX (cms_index_content_by_idhier) WHERE content_id IN (59,87,90,91,60,15,95,96) ORDER BY hierarchy
Debug: (0.315368) - (usage: 14289184) - (peak: 14327840) (mysqli): SELECT * FROM cms_content FORCE INDEX (cms_index_content_by_idhier) WHERE content_id IN (88) ORDER BY hierarchy
Debug: (0.317361) - (usage: 14401304) - (peak: 14420476) (mysqli): SELECT * FROM cms_content FORCE INDEX (cms_index_content_by_idhier) WHERE content_id IN (92,89,93) ORDER BY hierarchy
Debug: (0.318647) - (usage: 14462136) - (peak: 14480324) (mysqli): SELECT * FROM cms_content FORCE INDEX (cms_index_content_by_idhier) WHERE content_id IN (94) ORDER BY hierarchy

[jeepin81]

sure thing... lots of data.

Code: Select all

oops.. to much to paste into here.

see .txt attachment.

[calguy1000]

I see some very concerning things. Your system is already consuming 28MB of RAM before it even tries to load the content. That's extremely abnormal. twice what mine is, and I have a crapload of modules installed. and at 0.4 seconds there I suspect your server may be overtaxed.

However, the attachment explains why it's taking so long on the PHP side, AND why it's chewing up so much memory.

CMSMS is optimized for not loading all pages. it loads from the top down.and uses separate queries to load children of each parent page. This is good on frontend displays where you only have to display a subset of the navigation. But sucks on the content editing sites when you have a deep or complex tree structure.

I have a suspicion that if you were to use chrome's debug tools to look at what was happening you would get a hint as to the editors are taking dramatically longer to load. Probably network latency or something... Maybe the server is too busy wrt swap or something.

Is this shared hosting or dedicated hosting (VPS)? is the mysql host set to 'localhost' or some other hostname (having a remote mysql host has been proven to be much slower than using localhost where the loopback adapter can be used).

[jeepin81]

Here's our setup:

- Locally hosted virtual(VMW) windows server 2008 R2 Standard
- 8GM RAM
- 64 bit
- 2.67GHz Intel Xeon Processor
- WAMP Stack
- 1.11.7 Genovesa

When I run chromes PageSpeed it does indicate a slow response time for the edit page it's around 51 seconds for the 1st response for page:

10.x.x.x/cms/admin/editcontent.php_sx_=xxxxxxxx&content_id=15&page=

The other things it mention seem pretty minuscule.

One question: why would the response time between our production CMSMS and the fresh install I have bee so drastic? Is that b/c of all the site content we have out there?

You mentioned a complex tree structure and I know our CS Department has their daily news nested.. something like '4.10.1.8.23.1' if you look at the menu... and we have about 3 years worth of that stuff up there.

When I view the source some of the drop downs for the images are pretty extensive as well.

Sorry to be a pain.. I just don't know what steps I can take next.

[calguy1000]

It seems you have a double whammy: You have a site that is the worst case scenario for CMSMS: way too many pages in a deeply distributed page hierarchy I parsed through your text file and there seems to be ~1700 pages. The second whammy is using a windoze server.

We will see about addressing the first issue in version 2 of CMSMS.

WRT the second whammy I did some googling and it seems that wamp is very slow in windows (and probably earlier versions of windoze) out of the box. There are alot of threads about this in various forums with a lot of different tweaks you can try.

You will have to try googling stuff like "windows 8 wamp php slow" and follow some of their advice.

I would also try to install something like eAccelerator or APC opcode cache. and make sure that xdebug is turned off.

One of the things you can try right off the bat is:
edit the config.php and change:
$config['db_hostname'] = 'localhost';
to
$config['db_hostname'] = '127.0.0.1';

If that significantly improves performance then you know you will have to tune your server.

This just affirms my belief that I would never recommend anybody use windoze for a production web server (or anything for that matter). It may be 'ok' for a development server on a localhost laptop, but not for a production server.

[jeepin81]

I apologize for the late reply..

We are going to take your advice from the post above..

first step for us is to migrate to a LAMP stack either on Ubuntu or CentOS.

second step is to clean up those nested pages and reduce data... I don't think we need 3+ years of daily news.

If we don't notice any performance increases we'll install eAccelerator and probably install the ScriptDeploy module. Has anyone seen improvements w/ ScriptDeploy? What about GZIP Apache compression?

One other ?? - is there a release date set for CMSMS2.0?

Again, I really appreciate all the insight.

[calguy1000]

Use a module like 'News' for daily news... that's exactly what it's built for, and it is optimized to handle data of that type.

Using gZip compression is just a matter of enabling the appropriate apache module, and using the standard sample htaccess file that comes with CMSMS.

Scriptdeploy by all accounts looks abandoned.

[jeepin81]

calguy....

Thanks again for the info/suggestions.

One thing we tried that really seemed to help with improvement without any other changes was switching to the FCKeditorX Module. Not sure why? My guess is the nested pages as we discussed before.

After installing that module we made the following changes:

- we created a "history" site to archive a lot of our daily data.
- Got gZip going.
- Converting our daily news to a the actual news module.
- Purging older data
- Re-working our pages that are nested deeply

Future plans
- get off of "windoze" & toss CMSMS on a LAMP stack
- wait for 2.0

All that being said.. we have seen a great increase in speed and plan to stick with our setup until 2.0 is alive.

Again, I appreciate all of the help.

We have the beast version backed-up, so if you want us to beta 2.0 with that massive database with nested pages.... let us know.

Best....