Time out on editing or adding content

[baresi]

This is a site with many many pages that was upgraded from a working old version following the docs and checking required changes as best as I could. Upgrade seems to have gone fine (except some foreign character which I think I fixed with 'set_names')

Site seems fine as far accessing the front end and various admin pages except when submitting, applying or adding new content. When loading listcontent from Content ---> Pages it loads ok too but not when editing or submitting or even just clicking apply. Browser window acts as if it's loading a page until the (high) server connection times out.

Like mentioned above this site has many pages so listcontent is big but it loaded fine on older cmsms with worse server specs and php 5.2 too.

No errors in logs, confirmed with host.

Just a shot in the dark, is there something with Litespeed and cmsms that can cause an issue, perhaps?

Any help appreciated. And if anybody can give me a few minutes to look I will send login details, TIA.

----------------------------------------------
Cms Version: 1.11.13
Installed Modules:
CMSMailer: 5.2.2
FileManager: 1.4.5
MenuManager: 1.8.6
ModuleManager: 1.5.8
News: 2.15
Printing: 0.2.3
Search: 1.7.12
ThemeManager: 1.1.8
TinyMCE: 2.4.0
CMSPrinting: 1.0.5
MicroTiny: 1.2.9

Config Information:
php_memory_limit:
process_whole_template:
max_upload_size: 50000000
url_rewriting: mod_rewrite
page_extension: .php
query_var: page
image_manipulation_prog: GD
auto_alias_content: true
locale:
default_encoding:
admin_encoding: utf-8
set_names: false

Php Information:
phpversion: 5.4.44
md5_function: On (True)
gd_version: 2
tempnam_function: On (True)
magic_quotes_runtime: Off (False)
E_STRICT: 2048
E_DEPRECATED: 8192
memory_limit: 512M
max_execution_time: 300
output_buffering: 4096
safe_mode: Off (False)
file_uploads: On (True)
post_max_size: 50M
upload_max_filesize: 50M
session_save_path: /tmp (0700)
session_use_cookies: On (True)
xml_function: On (True)
xmlreader_class: On (True)

Server Information:
Server Api: litespeed
Server Db Type: MySQL (mysql)
Server Db Version: 5.5.42
Server Db Grants: Found a "GRANT ALL" statement that appears to be suitable
Server Time Diff: No filesystem time difference found

----------------------------------------------

[calguy1000]

How many pages are we talking about? 500? 750? 1000? more?

We never really tested the 1.x series with more than about 600 pages.

If listcontent is working fine, but apply/save when editing content is timing out then I would suspect that the issue is with the number of sql queries required to update the page hierarchies. As that is the only really expensive operation that occurs when saving a content page.

It literally has to adjust each and every row of the content table when you save a page because there is some metadata in there with respect to the page hierarchy location. This results in a lot of database queries (one for each page) which can be slow depending upon your host configuration.

Is your database host set to 'localhost' in the config.php file or is it a remote host?

[Rolf]

Try to disable Search module...

[baresi]

Thanks for the reply, we are talking closer to 4000, I can imagine that's way too many.
Edit/save was not the fastest but always worked (with that many pages) on old cmsms (1.3.1 and older for example) and php5.2. Every other thing is now better; ofcourse the cmsms version, php version, execution time even server specs including RAM and number of accounts on server, etc.

DB is localhost

Just as typing I renamed the search folder to see if Rolf's idea helps, will post back shortly. But that means removing search from templates for frontend to work? (which is fine for testing)

[baresi]

After changing search folder's name some edits (not all) are happening. Should I take this as no Search helps lower listcontent.php load a bit?
Any ideas what next ... Should I continue with cmsms and that many pages? if older version on Apache worked better, should I take the risk and try on an Apache instead of Litespeed host?

TIA

[calguy1000]

Search is executing more queries when the content is edited, to keep it's index alive, but I don't think that this is the primary problem.

I also don't think it's an apache vs. anything else issue. I think it's a matter of overloading the mysql system with way too many queries.

When a content page is edited in CMSMS there is a function that edits each and every row of the content table to update it's metadata (specifically the various hierarchy position stuff). This has to happen because you may have changed the page alias, or it's parent... which could effect not only the page you are editing, but it's former peers.

This method is very inefficient in CMSMS. If the average depth of all of your pages was 4, and you had 4000 pages. then this would result in (by my estimation).... ~20000 queries. just to update those positions.

I have a new, highly optimized version of the function that I am currently testing that would cut this number of queries down to something like: 1+number_of_former_peers. I am currently testing it myself, and then will ask the other dev team members to test.

[baresi]

Is that something that would be compatible with 1.11/1.12? If so, how soon may it be available? Not asking for a date, only if it's soon(ish) or not

[calguy1000]

if it works as expected, and tests good... then it will be out as soon as we can get all of the votes for release, prepare all of the announcements, etc.

[baresi]

Understood, thanks

[calguy1000]

CMSMS 1.12.1 has been released. It 'should' help with your problem as we fixed one function that would cause an extremely large amount of database queries on a site your size, and therefore could 'flood' the mysql server, and cause delays, and therefore timeouts.

Please test on a copy of the site.

[baresi]

Thanks calguy, will test on copy and report back.

[baresi]

At 1.12 turned on debug mode, saw 16667 mysql lines in the page after submitting/applying
After update to 1.12.1, I tried once and I see 3947.

I assume that's the correct way to check? ie count mysql statements shown in browser after clicking Submit

Big reduction. Thanks calguy and devs.

[calguy1000]

At 1.12 turned on debug mode, saw 16667 mysql lines in the page after submitting/applying
After update to 1.12.1, I tried once and I see 3947.

3947 is still huge for updating page contents.... something really wonky must be happening on your system.

[baresi]

Probably true, partly due to the way I started using cmsms years ago and just adding pages.

I don't know if I am asking the right question but hope you can give me a rough idea with this.
You mentioned earlier that queries down to 1+number_of_former_peers.

Just as an example, let's say my pages are:

Code: Select all

A section header
  150 content pages
B section
  150 content pages
.
.
.
Z section
  150 content pages

I edit a page in the A section.

What should I be seeing as number of queries?

[calguy1000]

Well, not counting content properties. I forgot about those... there are a few fixed ones for each page, and then whatever content blocks you have added... also, each 'word' is added separately to the search index... so there are a number of queries there. Therefore the number of queries really depends on your content length and number of properties. On my simple stock install, when editing the home page I get around 150 queries.

As well, I found that there is yet a further optimization (actually it's a minor expression error) in the last optimization that means it's not as efficient as it could be. I'll check it out and commit the change for whenever we do a 1.12.2