Magento 2 preinstall improvements
It is possible to order a Hypernode with a preinstalled Magento 2 application, or even preinstall Magento 2 on an existing Hypernode. This preinstall has received some changes lately:
- The store email addresses are now configured with noreply@<appname>.hypernode.io, so now emails sent will actually arrive in your inbox.
- The preinstall is now installed with composer create-project using our Mage OS Composer repository. Previously we managed tarballs for specific Magento versions and used extracted those tarballs onto a Hypernode. Now we don’t have to maintain those tarballs anymore. It is now also possible to run composer update without having Magento credentials configured on your Hypernode.
Varnish 6 thread pools on big plans
We have found that Varnish 6 has a maximum thread_pools value of 32 and that value was being exceeded on bigger plans. Now that value is being limited to 32, with each thread pool containing 25 threads at minimum and 2000 threads at maximum. So in heavy loads, it could spawn up to 64000 Varnish worker threads. We also found that it is now recommended to have no more than 2 thread pools and really just tweak the maximum threads in a thread pool, so we’ll look into that.
phpMyAdmin 5.x
In the past few months we have received some feedback from our users that they were experiencing issues with the phpMyAdmin functionality when having higher PHP versions. This was because we were still running phpMyAdmin 4.x, which wasn’t compatible with the latest PHP versions. From now on we will install phpMyAdmin 5.x for Hypernodes with PHP version >= 7.1 and phpMyAdmin 4.x for Hypernodes with PHP version <= 7.0.
NGINX OCSP caching
On our platform we make use of OCSP stapling, which is a mechanism that gives the client proof that the SSL certificate is still valid without the client having to check with the certificate authority. It basically offloads that checking by performing the check server side and providing a valid OCSP response by the certificate authority. That response is cached, so that the webserver (NGINX in our case) doesn’t need to check for every request.
We have a mechanism in place that warms all the OCSP caches for the webserver when reloading NGINX. Still, we were receiving some feedback from customers that they found invalid OCSP responses. After investigation we found that our nginx config reloader didn’t make use of the reload strategy, which caused the OCSP cached to not be warmed. We have fixed that now, so users should experience a lot less OCSP response issues.