PHP 7.4 vs PHP 8.1 Magento 2 an Adobe Commerce Performance

Magento 2 is well-known as the slowest PHP framework possible. Adobe doesn’t want to fix these issues. The same as doesn’t want refund to the merchants for the wasted money on implementations on top of the defective and overadvertised Adobe Commerce (formerly known as Magento 2 Platform)

The only hopes merchants and the community have are Open Source Magento Fork and new PHP release(8.1) performance improvements. Let’s check how PHP 7.4 and 8.1 performance differs.

Test Cases :

1. CMS page
2. Product Page
3. Category Page
4. Graphic and API performance
5. Di:compile time
6. Static content deploy

Each test case, we will run 10 times.

For the test, we will use the best docker environment for Magento:

Magento 2 install local or remote environment using Docker and Visual Code CODE

We will use AWS T3.medium EC2 instance. 2Cpu 4Gb RAM. Size doesn't matter for a single page performance test.

Install Magento environment

docker run --name magento2 -d -p 80:80 genaker/magento2-project

By default, this docker has PHP 7.4

We can upgrade it to the latest version :

yum upgrade php*

So now we have the next PHP 7.4 version :

Upgraded:
  php-7.4.19-1.module_el8.5.0+815+1c4fd2e5.x86_64                                                            
  php-bcmath-7.4.19-1.module_el8.5.0+815+1c4fd2e5.x86_64                                                     
  php-cli-7.4.19-1.module_el8.5.0+815+1c4fd2e5.x86_64                                                        
  php-common-7.4.19-1.module_el8.5.0+815+1c4fd2e5.x86_64                                                     
  php-devel-7.4.19-1.module_el8.5.0+815+1c4fd2e5.x86_64                                                      
  php-fpm-7.4.19-1.module_el8.5.0+815+1c4fd2e5.x86_64                                                        
  php-gd-7.4.19-1.module_el8.5.0+815+1c4fd2e5.x86_64                                                         
  php-intl-7.4.19-1.module_el8.5.0+815+1c4fd2e5.x86_64                                                       
  php-json-7.4.19-1.module_el8.5.0+815+1c4fd2e5.x86_64                                                       
  php-mbstring-7.4.19-1.module_el8.5.0+815+1c4fd2e5.x86_64                                                   
  php-mysqlnd-7.4.19-1.module_el8.5.0+815+1c4fd2e5.x86_64                                                    
  php-opcache-7.4.19-1.module_el8.5.0+815+1c4fd2e5.x86_64                                                    
  php-pdo-7.4.19-1.module_el8.5.0+815+1c4fd2e5.x86_64                                                        
  php-process-7.4.19-1.module_el8.5.0+815+1c4fd2e5.x86_64                                                    
  php-soap-7.4.19-1.module_el8.5.0+815+1c4fd2e5.x86_64                                                       
  php-xml-7.4.19-1.module_el8.5.0+815+1c4fd2e5.x86_64

CMS page performance:

first disabling full-page cache in the app/etc/env.php for a better understanding f the Magento framework:

‘full_page’ => 0,

Result: 140ms with the longes response 193ms

Product Page

Result: 256ms with the longest response 328ms

Category Page

Result: 259ms with the longest request 332ms

Di:compile performance

first removing the generated folder and after running

rm -rf generated/*
time bin/magento setup:di:compile

Result: 31 sec

Static content deploy

The same removing static files first

rm -rf pub/static/*
time bin/magento setup:static-content:deploy -f

Result: 19.13 s

Ok, now we need install/update PHP8.1. To update on AWS Linux or any other RHL you can use this repo and script:

GitHub - Genaker/Magento-AWS-Linux-2-Installation: Adobe Magento Commerce Cloud to AWS Cloud…

export PHP_VERSION=8.1
curl -s https://raw.githubusercontent.com/Genaker/Magento-AWS-Linux-2-Installation/master/install-php.sh | bash
supervisorctl restart php-fpm
# also you need add to the app/boostrap.php
error_reporting(E_ALL ^ E_DEPRECATED);

PHP 8.1 was released on November 25, 2021 by the PHP Development team for public use. PHP is a legacy scripting and programming language for the Web. Most web applications and dynamic web pages are created in PHP. Either by using vanilla PHP coding or Frameworks powered by PHP. In this test, we will install PHP 8.1 on Amazon Linux 2. Amazon Linux 2 is a Linux operating system from Amazon Web Services (AWS) designed to be secure, stable and to provide high performance.

Now we are using :

Magento 2 PHP 8.1 performance

CMS page

Result: 103ms with the 13 longest

Product Page

Result: 187ms with the longest request 230ms

Category Page

Result: 224ms with the longest 262ms

Di compile

Result:26.81s

Static content deploy

Result: 17.17s

CLI does have much improvements because it doesn’t have good opcahe.

The opcache.enable_cli option enables PHP OPcache when running PHP scripts from the command line (using the php command). However, keep in mind that for PHP 5.x the OPcache extension works by storing cached opcodes in the memory of the current process. This is only useful when the process that’s running PHP is going to be handling multiple requests that can reuse these opcodes, like in a web server or under FastCGI. For a process like the PHP CLI, which runs one “request” and exits, it just wastes memory and time.

Enabling some jit specific config

opcache.jit_buffer_size=100M

opcache.jit=1255

CMS page

Result: 96ms

Product Page

Result: 180ms

Result: 225ms

JIT in PHP8 does not affect classic web applications all that much, since by default PHP doesn’t use any long-running processes to handle requests like NodeJs or Java.

Magento 2 GrapQL PHP 7.4 vs PHP 8.1 performance

get category data API :

/graphql?query=query+GetCategories%28%24id%3AInt%21%24pageSize%3AInt%21%24currentPage%3AInt%21%24filters%3AProductAttributeFilterInput%21%24sort%3AProductAttributeSortInput%29%7Bcategory%28id%3A%24id%29%7Bid+...CategoryFragment+__typename%7Dproducts%28pageSize%3A%24pageSize+currentPage%3A%24currentPage+filter%3A%24filters+sort%3A%24sort%29%7B...ProductsFragment+__typename%7D%7Dfragment+CategoryFragment+on+CategoryTree%7Bid+meta_title+meta_keywords+meta_description+__typename%7Dfragment+ProductsFragment+on+Products%7Bitems%7Bid+uid+name+price_range%7Bmaximum_price%7Bregular_price%7Bcurrency+value+__typename%7D__typename%7D__typename%7Dsku+small_image%7Burl+__typename%7Dstock_status+type_id+url_key+__typename%7Dpage_info%7Btotal_pages+__typename%7Dtotal_count+__typename%7D&operationName=GetCategories&variables=%7B%22currentPage%22%3A1%2C%22id%22%3A22%2C%22filters%22%3A%7B%22category_id%22%3A%7B%22eq%22%3A%2222%22%7D%7D%2C%22pageSize%22%3A12%2C%22sort%22%3A%7B%22position%22%3A%22ASC%22%7D%7D

PHP 7.4 GraphQL

Result: 147ms with the longest 245ms

Magento GraphQL PHP 8.1

Result: 121ms with the longest 175ms

Graph Ql is a little bit lighter than the category page but a single Adobe PWA Studio page requires more HTTP requests. In our case 19 HTTP requests…

There are some benchmarks out there that claim the JIT has an immense impact on PHP performance, but these only measure specific code samples. The JIT opens doors for PHP into new areas of programming like async microservices, but we shouldn’t expect it to significantly impact our day-to-day PHP-fpm Magento framework web performance.

PHP 8 performance explained by Zend Technology PHP core engineer

there are only 2 main versions with huge performance PHP 5 and 7.

PHP8 JIT has improvements only on the static test but not for a real Web APP. On a real web CMS sometimes even slower…

After compiling op-cache byte-code we are running JIT compilation and generating native assembler code like V8 NodeJs JIT works.

• $$ is harmful for performance
• Static Typisation is harmful for performance
• According to the PHP core developers, WordPress is the most optimized CMS and Jit compilation will not help. WP is fast by default.
• JIt doesn’t improve the performance of the PHP core functions like json_decode(), preg_match(), strpos(), because they are implemented on C/C++ optimized, and compiled already. JIT improves the performance of the functionality written on pure PHP basically it is just a for loops. If you are writing infinity loop apps like demons and servers JIT will help you. If you just need Magento and PHP Classes it will not help you dramatically.

You can see a slight PHP performance improvement for Magento default Luma installation. But the main issues are not PHP performance but a bloated Magento 2 core framework. Adobe needs to fix platform performance and not just pray for new PHP release improvements. A new PHP version improves any other PHP-based platform (Sylius, ORO commerce, OpenMage/Magento1 etc.) and Magento 2 always stays behind and slow. Simply by fixing a single critical Magento performance bug and architecture issue you can improve performance much more them a new PHP 10 release.

Learning PHP 8 in 2022 is silly anyways, unless your job pays you well, the same compensation for yor wasted time as Pyron and NodeJs developers have. Javascript, Rust, Java, Python have better frameworks, and those languages have much more utilities and salaries than PHP. Needless to say, JS and Python are way easier to learn than cumbersome Magento 2.

Also, it is interesting how after 20 years of development, PHP still has so many issues which they can improve every release. Python and JavaScript, Java do not have much implements every release, mainly new features that simplify development. They are matured by design when PHP releases so much implement every release but can not be as fast as JavaScript or Python.

Pivot Table of the Adobe Commerce PHP 7.4 vs 8.1 performance

Chart:

This test is just an example of the Magento performance. The real Magento 2 performance depends on many factors: Server type (CPU) and Architecture (x86/ARM), hosting environment (on a Magento Commerce Cloud it will have the slower possible performance), 3d party and first-party extensions, Cron jobs, Database performance, number and types of products(SKUs), Redis performance, Elastic Search issues, indexes and cache invalidations, Core Web Vital Frontend issues, visitors traffic spices, boot traffic, Moon phases, and just random Magento 2 issues. PHP 8.0 40–50ms improvement will not make you feel safe with Magento 2 and will not make Magento 2 fast as PHP 7.0 did make it fast either.

I made a test sample PHP script. It just gets Empty Cart Data without any Controllers, MVC, Layouts, GraphQL, and other slow Magento patterns. And there is a result:

{“bootstrap”:0.060606956481934,”items”:[],”total”:{“subtotal”:{},”shipping”:{},”tax”:{},”grand_total”:{}},”time”:0.1302649974823}

Just to bootstrap MAgento 2 and do nothing takes 60 ms for the default installation. Load Empty Cart without any data takes 130 ms. It is just insane. Even simple Magento 2 code is really slowwwww.

Bonus: check what critical performance issues Adobe Commere with PHP 8.1 have

To check the Magento core defect we will use the XHProof profiler for PHP.

Just to create 1000+ Magento objects using DI takes 180ms.

Notice: Profiler has own overhead approximately x2. Op real request it takes ~ 180 / 2 = 90ms

Autoloader Takes 87 ms just to include all 1343 files…

Object Manager Compiled create takes 193ms

Magento\Framework\View\Result\Layout::renderResult = 68.6 ms

Magento\Theme\Block\Html\Topmenu\Interceptor = 17.7 ms

controller_action_predispatch = 45.0 ms

Bootstrap::create() = 11.1 ms

Magento Category Page is a total Bloatware :

Default (without any customisations) Luma Mahento category page has 367 MySQL requests and that takes 219 ms and 292 Redis requests it takes 44.7 ms and 4 Elastic Search requests it takes 45.2 ms

To create 6000+ objects takes 256 ms

Calculates Prices for 12 products takes 396ms ->

Magento\ConfigurableProduct\Pricing\Render\FinalPriceBox\Interceptor = 396 ms

Generate swatches Json data takes 257ms :

Magento\Swatches\Block\Product\Renderer\Listing\Configurable\Intercept- 257 ms

Magento\Persistent\Observer\CheckExpirePersistentQuoteObserver — 125 ms

Elasticsearch — /magento2_product_1/document/_search — 45.2 ms

SELECT catalog_product_entity, catalog_product_super_link — executed 24 times — 29.5 ms

SELECT catalog_product_entity_varchar, catalog_product_entity executed 12 times — 27.1 ms

SELECT catalog_product_super_attribute, catalog_product_entity executed 25 times — 22.8 ms

Magento\Theme\Block\Html\Topmenu\Interceptor = 43.6 ms

Just to load XML layout takes 77ms on every page:

Graph Ql issues :

Requires to create 2900+ objects

Visitor::visit — GraphQL\Language — 51.1 ms

As you can see it is not a PHP language performance issue. In most cases, it is a code bloat issue:

Magento 2 bloatware mem

In computer programming, code bloat refers to the presence of program code (source code or machine code) that is perceived as unnecessarily long, slow, or otherwise wasteful of resources.

Software bloat is a process whereby successive versions of a computer program become perceptibly slower, use more memory, disk space or processing power, or have higher hardware requirements than the previous version, while making only dubious user-perceptible improvements or suffering from feature creep. The term is not applied consistently; it is often used as a pejorative by end users (bloatware) to describe undesired user interface changes even if those changes had little or no effect on the hardware requirements. In long-lived software, perceived bloat can occur from the software servicing a large, diverse marketplace with many differing requirements. Most end users will feel they only need some limited subset of the available functions, and will regard the others as unnecessary bloat, even if end users with different requirements require those functions.

The term “bloatware” may be applied to software that has become bloated through inefficiency or accretion of features as outlined above. The term also commonly refers to software preinstalled on a device, usually by the hardware manufacturer, that is mostly unwanted by the purchaser.

The term may also be applied to the accumulation of unwanted and unused software elements that remain after partial and incomplete uninstallation. These elements may include whole programs, libraries, associated configuration information, or other data. Performance may deteriorate overall as a result of such leavings, as the unwanted software or software components can occupy memory, waste processing time, add disk I/O, consume storage and cause delays at system startup and shutdown. In the worst cases, the leftover software may interfere with the correct operation of wanted software. Bloatware can be easily removed if the user has root access on his or her device, though the rooting process has its own advantages and disadvantages, such as voiding the manufacturer’s warranty, and that certain software refuses to run on rooted devices.

Wiki

To check Your Magento 2 PHP performance you can use this Magento 2 Opcache ReactJS GUI extension:

GitHub - Genaker/Magento2OPcacheGUI: Magento 2 Opcache Control GUI using React Frontend…

Installation instruction:

composer require genaker/module-opcache --ignore-platform-reqs
bin/magento setup:upgrade
php -d"mempry_limit=5G" bin/magento setup:static-content:deploy -f

You will see a report like this: