Building Lesti_Fpc2

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

ab -n100 -c10

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"?>
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
  • Form_Key
  • SessionID
These problems and I guess a few more have to be solved. You can find the code on

Next Previous