It appears future came for us Magento developers in the end. Magento 2 platform is alive and kicking, and with it modern PHP tools like Composer entered our daily routine. And it's so much easier now the Composer is here to take care of my dependencies! Khm. Not so fast. To be honest, packaging software into neat fully decoupled packages is still a utopia. We model tightly coupled reality which is not something you can hide behind package manager. Nevertheless, there are some neat concepts behind Composer and Magento 2 working together, lets check it out.

Even though Magento 2 Admin clearly states that Built-In Application cache is not recommended for production use, most Magento stores I found through BuiltWith don't have Varnish configured yet. Additionally, I have the feeling that most Magento 2 developers do not have Varnish configured locally while developing. While Magento 2 page cache has been developed in a way that you should be able to transparently switch caching backends, this probably will not be the case in real life therefore getting to know idea of reverse proxy could come in handy.

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.

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 1.14.1.0 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.

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.