Selector extremly slow (and blocking the whole server)

[cpx3]

Hi to all,

I have a quite strange problem. If I open a page that contains the selector 

select_countries=oesterreich, begin=(start_date=''),begin=(start_date<=today),end=(end_date=''),end=(end_date>=today), template=template-news, checkbox_not_startpage=0, select_categories!=tipps|shortcuts, id!=, limit=5, sort=-created

things get so slow that I usually need to restart the whole server to be able to login to PW-admin. I attached the profiler output of the function and you can see that with the exactly same data the output time goes up to minutes... Any idea? When I put the selector in the debugger it has an execution time of about 1200 ms. The problem only seems to appear when the selector is (the first and only) part of a function. Any ideas?

Thanks in advance,

Bernhard

[ryan]

@cpx3 First, make sure that the issue isn't that the selector is getting called repeatedly in a loop or something. Once you've confirmed that it's only getting called once per request, the next step is to identify what in the selector is making is slow (1200ms is slow). Remove the "id!=" from the selector, as that doesn't do anything. Update the order of the selector to the following. This is the order that I think represents the most likely bottlenecks towards the end, and the least likely towards the front, so it'll be easier to debug in this order. 

template=template-news, limit=5, sort=-created, checkbox_not_startpage=0, checkbox_not_startpage=0, select_countries=oesterreich, select_categories!=tipps|shortcuts, begin=(start_date=''), begin=(start_date<=today), ending=(end_date=''), ending=(end_date>=today)

(Note that I've replaced your "end" with "ending" since "end" is a reserved word in PW, though it may not matter here.)

Using your debugger (Tracy?) start removing parts of the selector from the end, until it starts performing fast. For instance, first try removing this from the selector:

ending=(end_date=''), ending=(end_date>=today)

Note what difference it  makes, then remove this also:

begin=(start_date=''), begin=(start_date<=today)

and then this:

select_categories!=tipps|shortcuts

...and so on until you get to "limit=5" and stop there (don't remove "limit=5"). Let me know what you find. 

 

 

[cpx3]

Thanks again for the answer. Actually I only called that selector on a testpage which had nothing on it than this selector plus pages->find. The solution for the moment was to add a "minimum date"  (i.e. created>date_minim) which seemed to be the only possibility to increase speed. The interesting fact was however that the same selector with the same data (I did not change anything) worked from 1000 ms to 80000 ms.

[ryan]

@cpx3 There's definitely something strange going on with that selector performance, so I'd still recommend that strategy of removing things from it (in the order mentioned) to identify the bottleneck. Once we know the bottleneck we can focus in on the particular field or fieldtype that is having the performance issue and hopefully find a solution. That's interesting that adding a "created>date_minim" helped, but it makes sense as it would just reduce the quantity in the set from which it has to match, so likely the bottleneck is still there. How many pages total are in this site?