Friday 04 July 2014 12:35:59 pm - 5 replies
Diving into eZ Publish 5 SearchService
Friday 04 July 2014 2:12:07 pm
I agree that there is room for optimization in the new content engine.
It was built with a good-architecture-first approach, whereas the old one was designed and refined with a mixed goal of flexibility and scaling.
Luckily, having a solid foundation should mean that making big changes is easier.
The papi-cache and the locationSearch service are clear examples of important additions which have come through real-life feedback and which can make a night-and-day difference.
And we love feedback: the more eZ5 gets used on real-life projects, the more information will be fed back to Engineering and Product Management to drive decisions about prioritizing features for the next releases.
A good example is a jira issue, with a PR currently open, about bad performances happening when a role with content/read policies is assigned over a dozen times to the same user group, with different subtree limitations. Probably not a very common scenario, but still one which was in use at a supported customer, and one which will work much better in 5.4.
So please keep pestering us with jira issues and feature requests.
Last but not least: there are in fact multiple initiatives underway: besides optimizing the db-based search service, the solr-based search service should see the light of day for eZ 5.4, (caveat: so it was said at the conference in Oslo. Roadmaps are not contractual), meaning that you will have soon one more tool at your disposal when having to deal with performance / scalability problems.
Modified on Friday 04 July 2014 2:14:30 pm by Gaetano Giunta
Friday 04 July 2014 2:41:26 pm
As said by Gaetano we are working on improving this over time and there is several efforts underway to improve the situation. And both the Subtree Limitation permission issue and solr as mentioned above is also planned to be rolled out in 5.3.x fixes as well, the former will already see the light in 5.3.2 which will be out maybe already next week.
As for your specific issue, we did not have this on our radar, so as also said above, we need help on finding the issues and improve them. In most cases we can even do backports, but in this case while we can and should improve the normal search to be able to filter on languages, the real solution to your problem was a new feature: location search. This is a much lighter search, and much more suitable for menu generation, item listings and so on.
Modified on Friday 04 July 2014 2:42:02 pm by André R
Thursday 10 July 2014 10:12:26 am
It is possible to optimize the sql query to remove all unused policies for the current search.
See the following jira comment which descripes a solution for ezp4 which removes all (mostly all) policies which has no impact to the search
I think such an algorihm can improve ezp5 sql queries a lot.
Thursday 10 July 2014 10:17:10 am
Thanks Gaetano and André for your comments.
Regarding the features and use of SearchService, Petar Španja has written a great article: Fetching content in eZ Publish 5 using Search service. Highly recommended!
Thursday 10 July 2014 2:59:16 pm
I moved the discussion on query optimizer to new feature request: https://jira.ez.no/browse/EZP-23140
It is a good feature request, but I don't believe it solves the issue Donat has here, as it is more about languages and amount of data returned for the matching content objects, so making Donat's reported issue be about that: https://jira.ez.no/browse/EZP-23116
Note that the last one will need changes to API most likely, so will need some design work before we can jump on it, maybe something to tackle during summer camp in separate workshops.
Modified on Thursday 10 July 2014 3:24:08 pm by André R
You must be logged in to post messages in this topic!