Akeneo PIM 1.5 and the PHP 7 Support of the CLI
Recently, Nicolas Dupont discussed about our unit tests running on PHP 5.4, PHP 5.5, PHP 5.6, PHP 7 and HHVM. With this pull request, we achieved another step on the road toward PHP 7 support.
TL;DR
- Akeneo 1.5 CLI (imports, exports, mass operations, versioning process, completeness calculation…) now works with PHP 7 and MySQL as storage engine, and that rocks!
- the hybrid storage engine MySQL/MongoDB is not yet compatible with PHP 7 due to Doctrine not supporting PHP7 with MongoBD
Benchmarking our representative catalogs
Depending on the size of the catalog, there are 2 ways to store product data:
- either the whole catalog is stored in MySQL
- either products data (and only products data) is stored in MongoDB while the other parts of the catalog remains in MySQL
To determine wether you should use the hybrid storage or not for your catalog, simply follow this rule.
To ensure the application works correctly, we audited it with 3 representative catalogs. The small and medium catalogs can be used with the regular MySQL storage engine, while the large catalog can only work with the hybrid storage engine MySQL/MongoDB. These catalogs contain respectively 5k, 50k and 1M products resp. 160k, 3.6M and 52.7M product values.
I performed a series of benchmarks on my local machine (Core-i7@2Ghz, 8GB RAM) with xdebug disabled, in production environment of course. My PHP versions are 5.6.17–3 and 7.0.3–5 as of Debian testing. The following commands have been tested:
- installation of the PIM (pim:install): it checks the requirements of the PIM, creates the database, imports the catalog without the products data and installs the assets.
- import new products (akeneo:batch:job csv_product_import — config=’{”realTimeVersioning”: false}’): all products of the catalog are imported. As no products exist at this moment, there are only product creations. Real time history update (versioning) is disabled to allow running the versioning refresh command later.
- import updated products (akeneo:batch:job csv_product_import — config=’{”realTimeVersioning”: false}’): all products are once again imported, but they are all updated with random data, no matter their family or their requirements. This is not a real life use case, but it shows what can happen in the worst case: when your products are completely different between each import. Real time history update (versioning) is disabled to allow running the versioning refresh command later.
- versioning process (pim:versioning:refresh): products’ versioning are built to provide a complete history of the products.
Without any surprise, PHP 7 is far more rapid than PHP 5. All operations are between 1.5x and 2.6x times faster. Please do not take these values as granted. These are just benchmarks executed on my local machine and their only purpose is to compare PHP 5 and PHP 7, not to evaluate the PIM efficiency. You can expect better results on a production installation.
The important thing to notice, is that the bigger the import is, the more efficient PHP 7 is. Also, imports of existing products are even more efficient with PHP 7 than imports of non-existing products. This is surely due to the time spent in the Doctrine Unit of Work, particularly in the computeChangeSets methods. Those methods are CPU greedy and PHP 7 enhancements are particularly efficient on these kind of operations.
About the large catalog and the hybrid storage engine
As you may know, the PHP MongoDB team recently released a brand new version of their PHP driver called mongodb. This new driver is compatible with PHP 5, PHP 7 and HHVM and with all Mongo versions (2.4, 2.6, 3.0 and 3.2), which is totally awesome; one driver to rule them all. The legacy driver, called mongo, does not support PHP 7 or HHVM.
Last month, the Mongo team also released the 1.0.0 of the PHP userland library mongo-php-library which is a high-level abstraction of the new mongodb driver.
So everything seems perfect no? Well, almost…
The problem is that Akeneo PIM relies on Doctrine which is not yet compatible with the new mongodb driver and the mongo-php-library as explained in various GitHub tickets here, here and here. This is why I was not able to benchmark the large catalog with the hybrid storage engine.
But there are some good news. First, the Doctrine team is working hard to make the doctrine/mongodb-odm library compatible with the new mongodb driver. And judging by this tweet, it seems on a good way:
The other good news is that the upcoming mongodb driver will be supported in the very next versions of the Doctrine libraries:
The new driver should be properly supported once we release versions 1.1 and 1.3 of the ODM and underlying Doctrine MongoDB library, respectively.
And last, but not least, they’re working on an adapter between the legacy and the new driver. Why? Because the new mongdb driver and its userland library mongo-php-library are a complete rewrite, and are not compatible at all with the former versions. This adapter will allow us to use the new mongodb driver completely transparently, without backward compatibility breaks via Doctrine doctrine/mongodb-odm. And once again, it seems on a good way:
What’s next?
We’ll keep an eye on the progress of the Doctrine team on the new mongodb driver and we’ll try to test it as soon as possible. Let’s cross our fingers for Akeneo PIM 1.6 :)
To officially support PHP 7 on CLI, we’ll have to include it in our performance test suites and update our documentation.
Finally, we’ll also study the possibility to make the whole application, including the UI, work and be compatible with PHP 7.
