Details
-
Story
-
Resolution: Fixed
-
High
-
5.1, 5.2, 5.3, 5.4-dev
-
Castor Core S6
-
2
Description
TL;DR; Change Content Search SPI Handler to only return ContentInfo to avoid several extra queries and loading of all translations on search. Instead Search Service will hit the SPI Persistence cache to load the full object which will be faster.
Original description:
Having implemented several eZ 5 projects using the new stack only, mainly using 5.2 and 2014.01 versions, I have seen a considerable performance degradation of SearchService::findContent with increasing number of content objects and languages. Even simple things as fetching a subtree for a meta navigation became intolerably slow .
When investigating (https://github.com/ezsystems/ezpublish-kernel/blob/master/eZ/Publish/Core/Persistence/Legacy/Content/Search/Handler.php#L95) I found out that in order to retrieve the full content objects, a huge PHP array is created based on the SQL table resulting from different joins. To give you an impression of the size of this array: for a search resulting in 24 hits, this array had 44,880 rows with 39 elements each, with highly redundant data.
This is obviously slow and scales badly: A single search returning a subtree with 70 objects took twice as long as searching four locations individually for the same objects.
Attachments
Issue Links
- relates to
-
EZP-21755 Add multilanguage names property in ContentInfo
- Backlog
-
EZP-21171 No REST API to manage languages
- Closed
-
EZP-23643 Search with permissions off results in UnauthorizedException
- Closed
-
EZP-22191 As a User I expect API's with language filters to respect Always available flag
- Closed