upgrade to 3.5.1 : deleting takes 10 minutes?...

Author Message

Gioele Agostinelli

Saturday 05 March 2005 8:34:55 pm

Hi folks,

i just upgrade from 3.2.3 to 3.5.1. Everything seems fine but when i try to delete something (an article for example) it takes around 10 minutes! After investigation i always have a query similar to this one running when deleting:

| Query | 569 | Copying to tmp table | INSERT INTO eznode_count
SELECT
count( ezcot.main_node_id ) AS count
FROM
ezcontentobject_tree ezcot RIGHT JOIN
ezcontentobject_tree ezcot_all ON ezcot.main_node_id = ezcot_all.main_node_id
WHERE
ezcot.path_string like '/1/2/13540/%' and
ezcot.node_id != 13540
GROUP BY ezcot_all.main_node_id |

I'm on mysql 3.23.58. I have a large site with a lot of articles but i think that 10 minutes isn't normal... Thanks for the help and have a nice day!

Gioele

Raymond Bosman

Wednesday 09 March 2005 4:52:37 am

Ten minutes is not normal indeed. Can you check whether the main_node_id field of the ezcontentobject_tree table has an index?

If not create one on the main_node_id, this will definitely save a lot of time.

Raymond

Gioele Agostinelli

Wednesday 09 March 2005 1:10:08 pm

Hi Raymond,

Thank you for your suggestion, I added an index on main_node_id and now deletion of an object takes less then a second. The index isn't part of the sql schema by default; I think it should be a good idea to add it by default in next version of ez.

I also have another suggestion, I don't know if it is 100% bullet-proof but here it is anyway....

If I understood correctly, the query that was taking for ever is in subtreeSoleNodeCount(). This function is called by removeSubtrees() in kernel/classes/ezcontentobjecttreenode.php. If the object you are trying to delete isn't a container there shouldn't be any subtree and therefore no need to call the function subtreeSoleNodeCount() since it should always return 0. So I replaced the call of subtreeSoleNodeCount() in removeSubtrees() by :

if ( !$class->attribute( 'is_container' ) )
{
$soleNodeCount =0;
}
else
{
$soleNodeCount = $node->subtreeSoleNodeCount();
}

Since the only objects that I delete are articles which are not container on my site, deletion time returned to normal.

The modification is a bit dirty since the verification should be done in subtreeSoleNodeCount() and not in removeSubtrees()... but I was in a hurry... I'm sure you get the idea... there is no need to run the query if the object is not a container.

If I'm correct maybe it would be a good idea to add this kind of verification in next version of ez also.

Thank you again for your suggestion and have nice day!

Gioele

Jan Borsodi

Friday 11 March 2005 1:45:25 am

The <i>is_container</i> flag is merely meant as a user-interface hint than a strict rule for objects. This means that it is quite possible for an object to have children (e.g comments).

The reason why we check for children for all objects is to give the user feedback on how many children are going to be deleted. If we add this check children may be accidently removed.

--
Amos

Documentation: http://ez.no/ez_publish/documentation
FAQ: http://ez.no/ez_publish/documentation/faq

Ekkehard Dörre

Monday 29 August 2005 5:59:58 am

Same Problem with 3.5.3
MySQL 3.23.49-log debian 40 sec., creating index didn't help, same istallation on testserver xp with MySQL 4.0.20a in 3 sec

Deleting 1 Object. Any Ideas?

SOLVED, it is voodoo, tried it again after 10 minutes, now it works.

Thanks, ekke

http://www.coolscreen.de - Over 40 years of certified eZ Publish know-how: http://www.cjw-network.com
CJW Newsletter: http://projects.ez.no/cjw_newsletter - http://cjw-network.com/en/ez-publ...w-newsletter-multi-channel-marketing

Powered by eZ Publish™ CMS Open Source Web Content Management. Copyright © 1999-2014 eZ Systems AS (except where otherwise noted). All rights reserved.

eZ debug

Timing: Jan 18 2025 16:17:01
Script start
Timing: Jan 18 2025 16:17:01
Module start 'layout'
Timing: Jan 18 2025 16:17:01
Module start 'content'
Timing: Jan 18 2025 16:17:01
Module end 'content'
Timing: Jan 18 2025 16:17:01
Script end

Main resources:

Total runtime0.0210 sec
Peak memory usage2,048.0000 KB
Database Queries3

Timing points:

CheckpointStart (sec)Duration (sec)Memory at start (KB)Memory used (KB)
Script start 0.00000.0085 588.0391152.6406
Module start 'layout' 0.00850.0042 740.679739.4766
Module start 'content' 0.01270.0058 780.156393.3359
Module end 'content' 0.01840.0025 873.492238.3047
Script end 0.0209  911.7969 

Time accumulators:

 Accumulator Duration (sec) Duration (%) Count Average (sec)
Ini load
Load cache0.002712.8504140.0002
Check MTime0.00136.2528140.0001
Mysql Total
Database connection0.00199.142110.0019
Mysqli_queries0.004320.372630.0014
Looping result0.00000.114910.0000
Template Total0.00199.310.0019
Template load0.00125.796710.0012
Template processing0.00073.459110.0007
Override
Cache load0.00063.011010.0006
General
dbfile0.00031.337780.0000
String conversion0.00000.056940.0000
Note: percentages do not add up to 100% because some accumulators overlap

Templates used to render the page:

UsageRequested templateTemplateTemplate loadedEditOverride
1print_pagelayout.tpl<No override>extension/community/design/community/templates/print_pagelayout.tplEdit templateOverride template
 Number of times templates used: 1
 Number of unique templates used: 1

Time used to render debug report: 0.0001 secs