When I check the query log publishing a single page generates about 13MB of querylog... However no single query takes more then 1 second to execute. It' s just a sick amount of queries that is being executed.

This pattern appears every x ms (a lot);
6 Query select pkID, paID from PagePermissionAssignments where cID = '1'
6 Query select paID, paIsInUse from PermissionAccess where paID = '3'
6 Query select paID, paIsInUse from PermissionAccess where paID = '4'
6 Query select paID, paIsInUse from PermissionAccess where paID = '5'
6 Query select paID, paIsInUse from PermissionAccess where paID = '6'
6 Query select paID, paIsInUse from PermissionAccess where paID = '11'
6 Query select paID, paIsInUse from PermissionAccess where paID = '15'
6 Query select paID, paIsInUse from PermissionAccess where paID = '16'
6 Query select paID, paIsInUse from PermissionAccess where paID = '17'
6 Query select paID, paIsInUse from PermissionAccess where paID = '19'
6 Query select paID, paIsInUse from PermissionAccess where paID = '14'
6 Query select paID, paIsInUse from PermissionAccess where paID = '13'
6 Query select paID, paIsInUse from PermissionAccess where paID = '12'
6 Query select paID, paIsInUse from PermissionAccess where paID = '8'
6 Query select paID, paIsInUse from PermissionAccess where paID = '18'
6 Query select paID, paIsInUse from PermissionAccess where paID = '9'
6 Query select paID, paIsInUse from PermissionAccess where paID = '10'

Does this have something to do with advanced permissions?
Can we try to turn that off?

Aha this seems to happens one for every page (perhaps because are most of them share the same parent).

Query select pkID, paID from PagePermissionAssignments where cID = '

Is executed for page cID 0,1,2 and 131 (which is the parent of all those pages being published).

So in publishing there is a loop somewhere that loops all pages which explains the symptoms.

This implementation does not seem to be salable at all if this is intended behavior.

interdasting.

i don't have a solution unfortunately but wouldn't be surprised if this is in fact intended behavior. from my experience whenever i've worked on more sophisticated sites with that many pages and performance requirements i've used other systems such as episerver or sharepoint.

Hi Cherrycake,

Yeah it was a gamble to go for a "less mature" CMS for this project. However Concrete5 seems to be a good choice up to now. It even does pretty well performance wise (lets say OK, because without Varnish it would be pretty resource hungry).

This issue however, is something we only see in the composer. All other aspects like publishing/changing/saving the page are not effected. So I was hoping a developer involved in this area would popup and point us to a way to work around this behavior, perhaps by making overrides.

If not we will have to figure this out ourselves...

Hello Andrew,

My colleague told me I could expect a reply from you ;-).

1. Yes, the composer is set to publish the page beneath another page. There is no sitemap to choose the parent page. Let call that page "news". All pages are published beneath "news". So "news" is cID 131 I referred to in my post. We made this choice for several reasons so we would like to keep it that way. The performance issue occurs in the "POST" request when hitting the blue publish button.

2. Good to hear that, The first thing I will try this Monday is an update in our dev environment. Will get back to you with the results. Thanks Andrew!

Hello Andrew,

After the update the POST dashboard/composer/write/save/ went from 1~3 minutes to 4 seconds on my first test (in dev). Nice!

We'll see how this works with our automated import. But I think this lowers the publish time to acceptable levels as it does not seems to be affected by the number of pages beneath the parent page (or entire system, not tested).

Unfortunately... My last statement will have to be discarded.

We're at 9000 pages and the publish time increased to 14 seconds in my dev env. So the relation between the number of pages and the publish time still exists, also in 5.6.1.2.

I will come back with the relevant queries later this week.... :-(.

Does 5612 still fill up the query_log with the repetitive queries?

Unfortunately, by default, this is c5's modus operandi -- lots of queries. But it's something that can be fixed relatively easily if you're willing to get your hands dirty.

I've been having a similar issue. I narrowed it down to the Page::movePageDisplayOrderToBottom() function. (actually, I think it's the Page::updateDisplayOrder() function, but can't really test it).

1. It loads all the pages under a parent using Page::getByID();
2. It does a Cache::delete on a bunch of hashes for each of the pages noted in step 1.

Any ideas how to proceed and get the timing down from ~1 minute?