The sweet spot of any Magento project from hosting standpoint is when traffic patterns allow that all services store in question needs, fit on a single more or less powerful machine. Having that singe IP address you connect to in order to deploy code, do system upgrades when traffic is low and monitor when traffic is high is super convenient. But as store grows in terms of traffic, sooner or later you'll be forced to think horizontally. This usually means adding load balancer, couple of frontend nodes as well as dedicated servers for other services your store requires. In other words, you need more machines configured in private network working together in order to serve more traffic. There are many challenges to setting up and maintaining such system, with having fast network through which your nodes communicate being the most important component of your infrastructure.Continue reading
Tracking how Magento 2 stands performance wise turned out to be quite a lesson in the area of enterprise software design for us all, especially after seeing how bad Magento 2 beta 3 vs Magento 184.108.40.206 EE performance comparison chart looks like. It's not that I enjoy pointing out flaws in the work other people do, what interests me is how certain design decisions affect how well platform at hand fits the requirements and how to avoid the same pitfalls when architecting my own code. So it's true Magento 2 performed poorly when compared to Magento 1.x Enterprise Edition just couple of months ago, lets see how it performs after seeing much of Magento 2 core team resources directed into that single requirement of increased performance and scalability.Continue reading
General consensus amongst developers playing with current Magento 2 development versions is that is appears to be much slower than Magento 1.x. Unfortunately before the public release of performance toolkit package for both platforms, it was quite hard to quantify performance regression in Magento 2. Performance toolkit was released last year, therefore I did the first benchmark using official tools for my Meet Magento Poland 2014 talk. Performance results were not impressive, but since Magento 2 just started to take shape, that was OK.
Recently I had the privilege of presenting benchmark results for current state of Magento 2 code to significant part of Magento community. In communication with some of the community members, I promised to publish detailed benchmark results, hence this article.Continue reading
It didn't take long after Colin Mollenhour released it's
Cm_Cache_Backend_Redis into the wild for Redis to become preferred cache storage backend in Magento world. With Magento 2 approaching rapidly, it's nice to know that once it goes GA, we'll find our good old
Cm_Cache_Backend_Redis inside. But, since our familiar
app/etc/local.xml has been replaced by
app/etc/env.php, how exactly do we switch cache backends in Magento 2? Luckily not much has changed and basics of switching cache backends is just a matter of syntax, as I'll explain in this article. Additionally, although this isn't proper approach to configuring cache backends in Magento 2, by adjusting dependency injection container configuration, I'll demonstrate how
app/etc/di.xml connects ins and outs of Magento 2 platform.
Before we seriously step into Magento 2 era, please allow me to dissect one more Magento 1 bug. Couple of weeks ago we enabled compilation at one of our client's Magento EE installation as a part of holiday traffic preparations. Goal was to take advantage of performance boost provided by avoiding Magento autoloader through compiling all the Magento classes into several bulky PHP files. Unfortunately things didn't go to plan and we had to disable compilation couple of days later, due to bug in the way catalog product view controller handles 404 forwarding when product exists, but for some reason it isn't viewable (out of stock, disabled, etc.).Continue reading