Thursday 01 May 2008 8:35:30 am

Are your db indexes set ? It's very strange...

By the way, I see that you hve 138 queries on one page !?!
- Have you enabled the cache on the identified server ?
- If yes, is the Smart cache policies well defined ?
- Do you use cache blocks ?

Hope it will help you.

Maxime Thomas
maxime.thomas@wascou.org | www.wascou.org | http://twitter.com/wascou

Company Blog : http://www.wascou.org/eng/Company/Blog
Technical Blog : http://share.ez.no/blogs/maxime-thomas

Thursday 01 May 2008 3:22:25 pm

Do you have all the 2500 blog posts in 1 node?
node id: 1081?

eZ Online Editor 5: http://projects.ez.no/ezoe || eZJSCore (Ajax): http://projects.ez.no/ezjscore || eZ Publish EE http://ez.no/eZPublish/eZ-Publish-Enterprise-Subscription
@: http://twitter.com/andrerom

Friday 02 May 2008 1:46:17 am

Hi

take the last version of ezcontentobjecttree.php .
With the old version , mysql query generate by Fetch list and fetch list count didn't use index.
The new version will replace path_string like '/1/2/1081/%' by parent_node_id =1081.

It should be faster.

http://www.kouz-cooking.fr

Friday 02 May 2008 6:51:35 am

Apparently, the problem disappeared after a mysql repair table action.
It's strange because the check table action didn't report any trouble.

Friday 02 May 2008 1:47:29 pm

hi brno,

I have slow querys when i'm reading from some nodes that contains thousands nodes.
when you say that "Apparently, the problem disappeared after a mysql repair table action.
It's strange because the check table action didn't report any trouble."
do you use myisam or innodb?

thanks,
fran

Iguana IT, SL - http://www.iguanait.com

Saturday 03 May 2008 11:20:49 am

<i>do you use myisam or innodb?</i>
I use myisam.
I would not affirm that the repair table action resolved the slow query.
I'm not a mysql expert but I can easly guess that the count query took more memory than my server has. If I'm right, it means that the same problem can occure soon when adding new nodes.
This is a bad surprise as I could not imagine that counting 2500 objects can take so much performance.

Francesca, do you have the same slow query ?

André : In the case of my blog, it's true that I can easly re-organize the posts. But as Piotrek said, subdivision is not logic in any case. Is there any study about how performance falls with nodes quantity ? It would help to organize a new project according to the server performance and prevent this kind of problem.

Sunday 04 May 2008 11:31:30 pm

> Maybe it's in the roadmap? Will it come with version 4.5 and new content status?

Content object status has to do with workflows, not content.

> Is there any study about how performance falls with nodes quantity?

I'll ask.

EDIT: There isn't a written study on this, basically you might start to see issues when you reach 20 000 nodes or more in one single folder. But it depends on mysql setup (server and config) and what sorting you use on that node. I would guess that sorting on content attributes have a higher overhead then sorting on stuff that is on the content object or content node tables (section,published, modified, modified_subnode, path, path_string, priority, class_identifier and name).

So this issue is something else, or a very badly configured mysql server.

eZ Online Editor 5: http://projects.ez.no/ezoe || eZJSCore (Ajax): http://projects.ez.no/ezjscore || eZ Publish EE http://ez.no/eZPublish/eZ-Publish-Enterprise-Subscription
@: http://twitter.com/andrerom

Thursday 03 July 2008 2:00:05 pm

From my own experience, 10000 objects under 1 node does not introduce any performance problems. What's done with those objects? Listing active objects (=attribute filter), custom filtering for some people (= more attribute filtering), google navigator. Some more stuff happens in a programmatic way, like re-publishing, but isn't slowed down either. We do hide "old" content under that node, but the admin interface isn't slowed down either.

The real bottleneck on the page providing the listing is (even after all those years) the template system. Over the years, I've been able to optimize that page using new features which brought processing time from 7-8 seconds to 1.5 seconds. More than a second of that time goes to the template system, which is for a big part caused by the complex fetch condition building.

So if you're not even going to do some tempalting on top of the node, it'll take even longer before you hit performance degradation.

Hans
http://blog.hansmelis.be

Thursday 07 August 2008 7:59:48 am

Hi
Actually I have similar problem. I have a kind of RSS Reader which generate about 10 000 Posts monthly on my eZ Publish site under about ten parent nodes. It is based on a Blog and it uses tags keywordlist, tagcloud , ezarchive and callendar like a Blog.

After few thousands of posts the tagcloud tamplate generates very long time SQL query and website is unusable and hangs MySQL server!

Below there is query from container node which contains only 4 tags in RSS Post. I moved them for tests, rest of them are in second rss container ( about 10 000 nodes with tags)

query from eztagcloud.php

Notice: eZMySQLDB::query(4 rows, 275,056.335 ms) query number per page:58

SELECT DISTINCT ezkeyword.keyword
                                            FROM ezkeyword,
                                                ezkeyword_attribute_link,
                                                ezcontentobject,
                                                ezcontentobject_attribute,
                                                ezcontentobject_tree,
                                                ezcontentclass
                                            WHERE ezkeyword.id = ezkeyword_attribute_link.keyword_id
                                                AND ezkeyword_attribute_link.objectattribute_id = ezcontentobject_attribute.id
                                                AND ezcontentobject_attribute.contentobject_id = ezcontentobject_tree.contentobject_id
                                                AND ezkeyword.class_id = ezcontentclass.id
                                                AND ezcontentclass.id = ezcontentobject.contentclass_id
                                                AND ezcontentclass.version = '0'
                                                AND ezcontentobject.status = '1'
                                                AND ezcontentobject_attribute.version = ezcontentobject.current_version
                                                AND ezcontentobject_tree.main_node_id = ezcontentobject_tree.node_id
                                                AND ezcontentobject_tree.path_string like '/1/2/12245/%'
                                                AND ezcontentobject_tree.node_id != 12245
                                                AND ezcontentclass.identifier = 'rss_post'
                                                AND 
 ezcontentobject.language_mask & 3 > 0 

                                            ORDER BY ezkeyword.keyword ASC

This is strange because the same query running in PhpMyAdmin takes about 87.5 ms !

after I disabled this line in extra_info.tpl all works fine...

{eztagcloud( hash( 'class_identifier', 'blog_post',
                                               'parent_node_id', $used_node.node_id ) )}

url /content/view/tagcloud/2 works very well

I see that this part of MySQL query slows and hangs my site

AND ezcontentobject_tree.path_string like '/1/2/12245/%'

Can anyone help here to fix this problem?
I think this is non optimised query problem or something with database tables
Mariusz.

Thursday 07 August 2008 11:33:10 am

Hans:
> More than a second of that time goes to the template system, which is for a big part caused by the complex fetch condition building.

If you can't efficiently cache the result of this code you should rewrite the code to a template operator, in php you can take advantage of the php api of eZ Publish to get a lot more efficient code.(list/tree fetch: eZContentObjectTreeNode::subTree)

eZ Online Editor 5: http://projects.ez.no/ezoe || eZJSCore (Ajax): http://projects.ez.no/ezjscore || eZ Publish EE http://ez.no/eZPublish/eZ-Publish-Enterprise-Subscription
@: http://twitter.com/andrerom