This site has been archived. To learn more about our current products Ibexa Content, Ibexa Experience, Ibexa Commerce head over to the Ibexa Developer Portal
By
Friday 17 October 2014 3:47:23 pm
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.
Main performance related changes in 5.3.3:
Other smaller changes also related to performance:
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
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
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%
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%
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%
Command (after adding languages in admin interface):
$ php ezpublish/console kb:measure:translate article ara-SA (...)
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%
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%
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%
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%
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.
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?