Forums / Developer / Performance using attribute_filter?

Performance using attribute_filter?

Author Message

Nicklas Lundgren

Tuesday 22 July 2008 3:10:01 am

Hi,
Whats your experience from using fetch with attribute_filter in very large sites?
In a site of ours, we have almost 150 000 contentobjects. Running the query below require about 30 seconds of pure MySQL work. It´s absolutely far too much.

We have also tried running it without the class_filter_array part of the code, but then it is even more slow.

From my perspective, the problem arises when the number of contentobjects climbs over about 50 000. Until then, we had ok performance.

Any ideas regarding how to handle this issue are very welcome!


fetch(content,list,hash(parent_node_id, $startpageNode.node_id,sort_by, $startpageNode.sort_array, class_filter_type,include, class_filter_array, array('article'),limit,1,attribute_filter,array('and', array('article/frontpageimage','=','0'))))}


Best regards,
/Nicklas

Nicklas Lundgren, Managing Director
Novitell AB, Sweden

André R.

Tuesday 22 July 2008 3:34:13 am

how many hits do you get with article/frontpageimage=0 ?
And why do you need to have so many articles in one folder?

If you split them up in logically separated folders, then you don't need to filter on such a big datasets (parent node id is filtered first).

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

Nicklas Lundgren

Tuesday 22 July 2008 5:44:39 am

Hi André,

Thanks for your reply.
I would say that about 80 000 object has frontpageimage=0, but we are only interested in the last published object, thats why we use limit, 1.

This is a news site. The content objects are already placed in the folders where they should be, we cant use a deeper hierarchy. And the number of content objects grows with about 6000 per day...
Also, we dont want to move older objects to some kind of archive folder, as they will then lose the url:s indexed in search engines.

The way MySQL handles the queries is really slowing down our results due to the huge amount of data in the database.

We are now trying to create our own operator for these kind of fetches, hopefully this will be faster.

Best regards,
/Nicklas

Nicklas Lundgren, Managing Director
Novitell AB, Sweden

André R.

Tuesday 22 July 2008 5:57:36 am

> We are now trying to create our own operator for these kind of fetches, hopefully this will be faster.

maybe, please post back if it helps or not.

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