After the tests on the new infrastructure for the client, we noticed that Page Load speed on the pre-live environment is slower than on the production. Scandiweb hopped on a mission to discover the reason for Page Load speed degradation on the new infrastructure, for the developers and the client to be able to address it.

Follow along the investigation process:

We noticed a performance degradation in the pre-live environment in comparison to the production environment. That didn’t necessarily mean that it was caused by an event on that date.

During a quick investigation, we assumed Amasty modules were updated on production but did not observe the same performance degradation as in the pre-live environment, therefore further detailed investigation was required.

After that, we performed extensive testing of the pre-live environment.

NewRelic performance

Because there was a need to gather statistical data to compare existing production with a pre-live environment, we shortly added NewRelic to the existing production environment to get it.

We measured a difference in performance with and without NewRelic and the numbers were shocking:

• For the current production environment, NewRelic adds from 40% to 60% to the total load time, which is an unacceptably high overhead
• For the pre-live environment, NewRelic adds 8% to the total load time, which is a tolerable tradeoff to get performance insights

Full-page cache (FPC) in Redis vs Varnish performance

There are 2 fast storage backends where Magento can store full page cache – Redis and Varnish.

Magento recommends using Varnish in their documentation, however, for some clients we see that Redis can be a faster solution (mainly for Magento 1). There were also reports about performance degradation switching to Varnish on current production (and Varnish is not used now).

We tested both, and the only difference was in cached pages. They load faster using Varnish. For uncached pages, there is no difference, and they load equally fast.

PHP 7.1 vs PHP 7.2 and cryptography performance

The main reason for starting the investigation was performance degradation compared to the current production environment.

Initially, the pre-live environment was running PHP 7.1, the same as the current production environment, but later it was upgraded to PHP 7.2.

We downgraded the pre-live environment to PHP 7.1, and the load time returned to the current production environment values.

NewRelic was very useful to understand why. If we compare two identical requests to the main page, we will see that in PHP 7.2, there is an additional “slow” code.

It is a code from PHP Secure Communications Library. Note that the “phpseclib_mdecrypt_generic” function is used. In PHP 7.1 stack trace, that code is present too, but NewRelic is not showing it, as it is executed very fast (because of the use of mcrypt which is a different library).

Since PHP 7.1, the mcrypt library was deprecated and removed from PHP 7.2. You can read more about it in the php.net article “mcrypt viking funeral“ (PHP guys have a sense of humor).

The “phpseclib”, used by Magento, has an algorithm of how it selects which library to use for cryptography. In short:

The prioritization is as follows: OpenSSL > mcrypt > pure-PHP
mcrypt and OpenSSL are loads faster than the pure-PHP implementation
mcrypt offers a 45x speedup over the internal mode, OpenSSL offers a 6.5x speedup over mcrypt.

Due to the absence of mcrypt library in PHP 7.2, phpseclib used pure-PHP cryptography implementation which is 45x times slower – that explains why we observe performance degradation.

A logical question here would be, why phpseclib is not using OpenSSL, which is 6.5x times faster than mcrypt and 300x times faster than pure-PHP implementation.

The logic of how phpseclib selects the cryptography backend is very complicated and depends on many variables. Quoting the same phpseclib contributor from GitHub:

If phpseclib is using mcrypt it’s doing so for speed purposes. Either (1) OpenSSL (which is faster than mcrypt) is unavailable or (2) it’s unsuitable for the given algorithm in question (eg. arcfour128 is being used or something; OpenSSL doesn’t support “incremental encryption” as mcrypt did; it can be emulated for block ciphers but not for stream ciphers).

PHP 7.1 vs PHP 7.2 and MySQL performance

After switching from PHP 7.2 to PHP 7.1, performance improved, but eventually, the page load increased. 17 hours later, the load time rapidly dropped and started to slowly degrade again.

Again, NewRelic was helpful to find out what exactly is slow. This time it was the MySQL database. 

Conclusions

Ideally, we suggest upgrading to the latest Magento 2.3 and PHP 7.2 because in Magento 2.3 legacy mcrypt dependency was replaced by a modern sodium library.

A go-live with Magento 2.2.10 and PHP 7.2 means degraded performance and a need to keep the plan of a switch to Magento 2.3 in mind.

Magento 2.2.10 and PHP 7.1, however, will result in fluctuating performance due to unknown database behavior.

Experiencing page performance issues with your Magento site? Is your store on Magento 2 slow? Shoot us a message and our Magento experts will see what they can do!

Share on: