Magento整页缓存和清漆

Question

I have been looking at full page caching in magento and something does not make sense with this and how dynamic blocks are sent.

For blocks containing dynamic data, the application still needs to be bootstrapped and the layout needs to be built in order to generate the blocks for example basket content, recently viewed etc

The server is now doing more work.

Is this correct and if so how to get around this

Answer 1

my 2 cents:

It depends on how you are doing your FPC...

"proxy cache"

If you are using some other caching frontend/proxy like nginx or varnish or [insert one here] then it REALLY decreases the load as you do:

1. one request to get the "frame" of the page which after its cached doesn't even touch php or magento or mysql, just serves a static file. So once its cached it doesn't need to bootstrap the app or load and parse any layout/config/system xml.
2. the second request is to get the dynamic content and is MUCH lighter. yes it still has to use the config/layout/system xml but that should already be cached AND it doesn't have to create/process that many blocks depending on the dynamic needs.

also depending on what you need you could store information in cookies to be used by js after the page loads and not do the second request, again depends on how dynamic and sensitive that dynamic information is.

So a request flow would be:

1. Request -> nginx/varnish/etc(super fast) -> response ...
2. ajax request -> Magento for dynamic content (lighter processing then if doing the whole page) -> response -> js replace elements.

Yes you do pay for the extra round trip, but you do get things to instantly load for the customer and while the ajax request is being processed the browser could be pulling images/css/other js from the server which is nice.

"Magento FPC"

Honestly I don't know how the enterprise edition does it (just haven't read the code) but before most (not all) things are processed there is a section that you can attach a cache processor. In that environment the application has already been bootstrapped and some of the configuration loaded, so you could actually pull the FPC from the cache and then replace the place holders their with the specific information and send that out in just one request.

Again request flow:

Request -> Magento (before routing etc) -> punch holes -> response.

So things don't start loading until the dynamic content is there, but you don't have the extra round trip.

Conculsion:

As far as which one is the best, well that just depends on your needs and setup. These are just two of the different setups I've seen and in my testing either method out performs having no FPC at all.

HTH

Answer 2

Not sure if I understand your question right but Magento and your server will do less work as it will only generate and deliver the hole punched, dynamic blocks which you define by XML. The rest of the page is static html delivered by varnish which does not even pass these requests on to magento.

Take a look at this chart from Fabrizio Branca's Blog:

Answer 3

yes the second request hits the server. it also loads the layout on line 30. this means that certain handles will loaded - default, customer_logged_out(or in) and the call controller (am i missing something?). in this blog http://www.fabrizio-branca.de/make-your-magento-store-fly-using-varnish.html it's suggested you add your place holder to the default handle. the unsetChild method allows you to still load the block by name in the call controller. the reason for this is described in some of alan storms blogs and (i think) a module of his deals with some of the problems regarding removed as opposed to unset blocks. cache invalidation isn't really handled by this module. maybe you should view this post magento open source full page cache