Magento 2 has finally seen it's general availability release as of late last year, and the rebuilt platform brings with it some valuable new additions such as ajax add to cart, editable admin grid rows and perhaps most significantly a full page cache for both community and enterprise versions of the platform. These are great additions as it means the core team has really been listening to what customers want and have built into the new version features which are real goto extension for Magento 1.
I have really enjoyed working with the Magento 2 codebase and I'll be honest, it really does feel light years ahead of Magento 1. Removal of the Mage 'god' class in favour of the functionality offered by the object manager and other more minor (but still significant) steps such as no more code pools and all extension files residing in the same directory location are really sensible steps. As well as listening to their customers, it seems like the core team have also really learnt from how Magento 1 was developed, used, and customised by third parties. Magento 2 feels like a really solid, defined platform to develop from with many areas that were considered to be open for discussion by many developers in Magento 1 being clearly defined in Magento 2.
If anything, you could argue that some of the functionality that is offered by the object manager has gone a bit too far, i.e. is basically overkill purely because at the moment it seems to cater only for real edge cases and might never prove that useful to third party developers. However these opinions may change as the platform matures and people get familiar with the full breadth of the codebase and what can be done with it. Ultimately, we developers certainly can't complain about Magento giving us more rather than less options, we just need to be sure we are using the right tools for the right application.
If you are interested in getting to grips with the object manager in Magento 2 then Alan Storm has a great series you can have a look at.
So finally getting to the point of the post, the addition of built in full page cache for Magento 2 creates a dilemma for third party extension developers (such as us) who have developed our own caching extensions for Magento 1. For us, we have to make a choice, do we port our caching solution to Magento 2 or does the built in solution negate the need for this? Unfortunately there is very little documentation covering the functionality of the full page cache in Magento 2, so we have instead been diving into the codebase in order to answer the above question.
It appears the core team have taken steps to make full page caching easier for their built in solution. They have made some noteworthy changes in Magento 2 such as category filtering now being restricted only to URL (where as it was also stored to the session in Magento 1), and storing the frontend form key to a cookie for quick and easy access (where it was only found again in the session for Magento 1). So removing dependency on the session when serving cached content seems to have been to some extent the order of the day.
When reviewing the full page cache logic my point of greatest interest was where and how the request was intercepted to serve cached content as opposed to the framework processing the request as normal. I expected to find an equivalent of the early request_processors hook in point used by the enterprise full page cache solution in Magento 1, but when investigating it seems that there is no equivalent in Magento 2. The core team have stuck firmly within the confines of the framework as it stands and used plugins to intercept the request, deciding at this point whether to serve cached content or send the request into the framework as normal.
My reason for being most interested in this intercept point is because full page caching id of course all about how fast you can deliver cached content to the browser, with the TTFB defining how long it takes for the page to start rendering in the browser - the longer this takes, the 'slower' the page is for the user. The choice of using a plugin is why I am rather disappointed with the performance of the built in full page cache for Magento 2 - it just isn't all that fast.
It's doing the right thing in development terms - using a plugin to intercept the request is not outside of the boundaries set by the framework, and is traceable and easy to find by third party developers as it's not using something else entirely (such as request_processors) to serve content, but the performance it gives is just pretty average. I wonder if any of the core team wanted to implement a faster solution with an earlier hook in point? We will probably never know.
The problem with using plugins is that in order to do this you need to instantiate the object manager, and this pretty much means instantiating the entire framework. Doing the equivalent of this in Magento 1 was slow, but Magento 2 is that much more complex and so takes even longer. An example - in my local development environment I see a TTFB of around 33% with the full page cache - so pages are served in around 6 seconds with caching disabled, and 2 seconds with caching enabled (using built in cache rather than Varnish). While this is a significant improvement, and production environments would have a faster setup with this process completing quicker, the percentage improvement would still be the same.
My issue here is that with Evolved Caching under Magento 1 you are looking at less that 1% of the time for TTFB (see the benchmarks) which is possible because full page cached content is served entirely outside of the Magento framework making it massively faster. There just really isn't any comparison between the two with around 33% being rather disappointing compared to less than 1%.
So to answer the original question, should we port Evolved Caching to Magento 2? Considering the performance we are seeing with the built in full page cache, I think the answer has to be yes. The challenge is building it in such a way that it gives equivalent performance to it's Magento 1 counterpart, yet falls within best development practices for Magento 2.
Keep your eyes open, but the Magento 2 version of Evolved Caching is under development and we will let you know when it's released.
No comments:
Post a Comment