New in 5.3.3 and 5.4: Improved API performance

When using the PHP API introduced in 5.0, there has been some rough edges when it comes to performance. This has steadily been improved in each release, and in the immediate next releases there are further changes. With 5.3.3 just out lets dive into those changes and benchmark some of them.

When we introduced 5.0 two years ago with both the old legacy stack (aka 4.x), and the new eZ Platform stack (aka 6.x stack) with it’s new REST & PHP API, it was announced that the new system had far more layers and that this would allow us to improve performance and scalability drastically over time. Without having to affect your code using PHP API and Symfony code much, or anything at all.

Example of this could be introduction a completely new database schema (“Storage Engine”) for better content scalability and speed. However until we reach our eZ Platform milestone next year where legacy will no longer be bundled, this is in one of the few changes which is not yet on the agenda because of BC. 

However quite some changes have already been done, main once was introduction of Repository (Persistence) cache in 5.1, Content and Context aware HTTP cache in 5.1 / 5.2 and Location Search in 5.3 for lighter tree based queries. While not strictly performance related, 5.3 also introduced support for newer faster versions of MySQL and MariaDB, and Doctrine DBAL for database provided a lot more debugging possibilities for queries performed on the system. 

New in 5.3.3 (and implicitly in 2014.11 and 5.4):

Main performance related changes in 5.3.3:

•  Reduce Search API queries and speed up search involving translations [EZP-23116]
•  Reduced Content objects build overhead by using ContentType cache [EZP-23333]
•  Get Content Search to use language filtering & always available flag [EZP-22191]

Other smaller changes also related to performance:

•  Lazy sessions are not honored in 5.3 [EZP-23176]
•  Binary Fieldtypes loads whole file to get mimetype with FS handler [EZP-23176]
•  Simplify low level legacy callbacks to not execute things like ezformtoken [EZP-22995]

If you want to read more about 5.3.3 you can directly head over to it’s release page to see more information including list of it’s 70+ bug fixes: https://doc.ez.no/display/EZP/5.3.3+Release+Notes

Benchmarking API improvements

Using the excellent MeasureBundle from partner Kuborgh GmbH we are able to benchmarking the API in several ways, including aging the content with adding more versions and translations to see how that affects performance.
To get started it first need to be installed on a clean eZ Publish 5.3 install with demo content, then secondly configured, example:

kuborgh_measure: 
   content_type_list_measurer:
        measurer1:
            service: 'kuborgh_measure.measurer.contentservice'
        measurer2:
            service: 'kuborgh_measure.measurer.locationcontent'
        measurer3:
            service: 'kuborgh_measure.measurer.searchcontent'

 These measure #1 content loading, #2 location search + content loading and #3 content search.
 After this we will perform the following command to run these measures with 100 iterations using article content type: $ php ezpublish/console kb:measure:performance_list -v --iterations 100 article

First iteration with standard demo content

 v2014.07.1 / v5.3.2

Result for: ContentService::loadContent
Avg. time:  3.614 ms    100%
Result for: SearchService::findLocation() => ContentService::loadContent
Avg. time:  8.330 ms    230%
Result for: SearchService::findContent
Avg. time:  13.330 ms   369%

 With EZP-23333: Reduced Content objects build overhead by using ContentType cache

Result for: ContentService::loadContent
Avg. time:  2.993 ms    100%
Result for: SearchService::findLocation() => ContentService::loadContent
Avg. time:  7.292 ms    244%
Result for: SearchService::findContent
Avg. time:  13.798 ms   461%

 Also with EZP-23116: Reduce Search API queries and speed up search involving translations

Result for: ContentService::loadContent
Avg. time:  2.373 ms    100%
Result for: SearchService::findLocation() => ContentService::loadContent
Avg. time:  6.851 ms    289%
Result for: SearchService::findContent
Avg. time:  6.624 ms    279%

Second iteration after adding 10 translations to demo content

Command (after adding languages in admin interface):

$ php ezpublish/console kb:measure:translate article ara-SA
(...)

 v2014.07.1 / v5.3.2

Result for: ContentService::loadContent
Avg. time:  15.131 ms   100%
Result for: SearchService::findLocation() => ContentService::loadContent
Avg. time:  17.753 ms   117%
Result for: SearchService::findContent
Avg. time:  158.835 ms  1050%

 With EZP-23333: Reduced Content objects build overhead by using ContentType cache

Result for: ContentService::loadContent
Avg. time:  12.579 ms   100%
Result for: SearchService::findLocation() => ContentService::loadContent
Avg. time:  15.930 ms   127%
Result for: SearchService::findContent
Avg. time:  155.755 ms  1238%

 Also with EZP-23116: Reduce Search API queries and speed up search involving translations

Result for: ContentService::loadContent
Avg. time:  9.898 ms    100%
Result for: SearchService::findLocation() => ContentService::loadContent
Avg. time:  15.791 ms   160%
Result for: SearchService::findContent
Avg. time:  15.112 ms   153%

 Also with EZP-22191: Get Content Search to use language filtering & always available flag

Result for: ContentService::loadContent
Avg. time:  3.572 ms    100%
Result for: SearchService::findLocation() => ContentService::loadContent
Avg. time:  8.511 ms    238%
Result for: SearchService::findContent
Avg. time:  7.370 ms    206%

Summary

 As illustrated in the graph above the changes have improved baseline speed of content loading and searching alike noticeably, made sure overhead of content search is faster than location search + content load as it should, keep impact of number of translations down and possible to avoid it almost completely by using language criterion and field filter for filtering languages.

However there is still some overhead in loading all languages, for now make sure to filter if you have several languages, in the future might end up filtering by siteaccess languages out of the box by means of a API decorator or query factory where conventions like siteaccess languages are applied.

Know about other places performance could be improved?

As always we need your feedback on cases where the product is not behaving optimally.
 We are aware that the system uses more memory with Doctrine DBAL as of 5.3 and hope to deal with that before 6.0. We also hope to deliver new search engine soon so API queries can be offloaded from database also, but as mentioned during summer camp we hit a blocker this summer caused by our introduction of location search which of course should also be powered by this.
So, do you know about other use cases where performance is not as you would expect?