I did start building Lesti_Fpc2. I always wanted a flexible and most compatible solution for Magento. That was never easy. So in Lesti_Fpc I did use the event controller_action_layout_generate_blocks_before as anchor. Just to explain, as anchor I mean the point were the Full Page Cache stops normal behavior of Magento and sends cached response. Normally you want to have this anchor as early as possible. My anchor was very flexible, but also not that fast as I expected.
Problems of old Lesti_Fpc
I made a test with Apache benchmarking tool on a product page in default Magento 184.108.40.206.
$ ab -n100 -c10 http://magento-1-8.dev/productpage.html
Magento without Lesti_Fpc
Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 0.1 0 1 Processing: 733 916 77.4 897 1121 Waiting: 709 891 77.8 874 1101 Total: 733 916 77.5 897 1121
Magento with Lesti_Fpc
Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 0.0 0 0 Processing: 406 532 61.5 526 903 Waiting: 396 518 60.8 512 892 Total: 406 532 61.5 527 903
Not that good. Just 59 percent of default Magento. We could say 1.7 times faster. Sure, with a bad template the differences would be bigger, but we want absolute performance. I always wanted the event controller_action_layout_generate_blocks_before as anchor cause in this moment Magento has build the hole session and has parsed the hole layout. So I just had to cut all non-dynamic blocks from layout, generate the dynamic blocks and replace them in the response. A second reason for this anchor was the possibility to make a difference between a category page with 30 and with 60 products. This is only possible with the value limit stored in customer session. But I just don’t want to miss this feature in Lesti_Fpc2.
Building dynamic blocks
An other problem was to build the dynamic blocks. I always have to render those blocks before sending response. But the better way would be to build those blocks before sending response of not cached actions. For example on the action checkout_cart_add. So I have build lazy blocks that are stored in session. But also lazy blocks will be rendered before sending cached response.
The idea behind Lesti_Fpc2
I just need an anchor that happens earlier. Many Full Page Caches set this anchor in front of Magento and want you to paste such a code at the top of index.php
This is maybe a few milliseconds faster, but this isn’t the way you should implement it in Magento. You should use the tag request_processors. How it works will be explained in this very good post from Luis Tineo. So I have build the file app/etc/fpc2_enable.xml.
<?xml version="1.0"?> <config> <global> <cache> <request_processors> <lt>Lesti_Fpc2_Model_Processor</lt> </request_processors> </cache> </global> </config>
This is also a very early anchor for a Full Page Cache.
Nothing works at this moment
The big problem with this early anchor in Magento was always for me, that I have no customer session. And like I have explained above, I want to use the session to build a very flexible Full Page Cache. And not only the session is missing, you haven’t anything from Magento. You can’t get a helper, a model, a block or configurations from database on the normal way. At this point you are a little bit outside of Magento. Only a few things work. We could build all these things if needed them, but that would only go the way of Magento and that costs too much time. So the idea is to share the needed parameters from customer session in my own session. And also the dynamic blocks will be stored in my own session. With every request that isn’t cached I will render dynamic blocks if necessary and write them into my session. And I will share parameters in between my session and the customer session. For example the limit I have exaplined above.
The current Implementation of Lesti_Fpc2
At this moment I just had implemented the way Luis Tineo has explained in his post and as expected the time for response is incredible. The same test like above.
Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 0.0 0 0 Processing: 25 37 10.9 31 78 Waiting: 24 35 10.3 30 76 Total: 25 37 10.9 31 78
We are 28 times faster.
Known problems will appear
To get a fast response time was never a problem. The real problem was always to let it work like Magento would behave without a Full Page Cache. Just a few things that are in my mind:
- Parameters in Session
- Messages Block
- Recently Viewed Products
These problems and I guess a few more have to be solved. You can find the code on github.com.