Full Page Cache Addon

HI there...

Is anyone using the full page cache addon? I was excited when I saw the team had developed a custom varnish implementation as I was thinking about doing this myself. I have hit the odd stumbling block, but in general, it seems to be installing ok and generating the correct VCL file which is activated in Varnish.

However, one thing I don't get about the code for the addon is this array:

'disable_for_extensions' => array(

'jpg', 'jpeg', 'png', 'gif', 'ico', 'tiff', 'tif', 'bmp', 'ppm', 'pgm', 'xcf', 'psd', 'webp', 'svg',

'css', 'js',

'html', 'txt',

'woff', 'eot', 'otf', 'ttf',

'zip', 'sql', 'tar', 'gz', 'tgz', 'bzip2', 'mp3', 'mp4', 'flv', 'ogg', 'swf',

),

This code is in app/addons/full_page_cache/schemas/full_page_cache/varnish.php

Basically this array is used to tell the varnish VCL file which files to ignore from the cache. Basically this list rules out most of the files used on any website. Which I don't understand. For example. My product pages use the .html extension and they are immediately excluded from the cache.

Maybe I don't quite understand their approach, but it seems wrong to me. If I make this an empty array and reactivate the addon then the page is cached and when its cached, it loads so much faster - I can't wait to get this running on my site.

I just want to understand their approach before I modify this file.

Cheers,

Nathan

Hi Nathan,

The "disable_for_extensions" pre-defined list is generic and is a subject to change to fit the needs of each concrete integration.

We specified a lot of extensions by default in order to Varnish couldn't cache static content, because this can be handled by Nginx. In other words, we tried to delegate static content delivery&caching to Nginx since it does it better.

However, feel free to change the list of extensions as you want.

Thanks.

Hi Nathan,

The "disable_for_extensions" pre-defined list is generic and is a subject to change to fit the needs of each concrete integration.

We specified a lot of extensions by default in order to Varnish couldn't cache static content, because this can be handled by Nginx. In other words, we tried to delegate static content delivery&caching to Nginx since it does it better.

However, feel free to change the list of extensions as you want.

Thanks.

HI there,

Thanks for the reply. I am not quite following as I thought that was really the purpose of Varnish to cache the content. Are you saying that varnish is better at handling the dynamic content caching with ESI and NGINX is better at handling the static content? Our setup is using Apache as that was the only supported webserver setup from CS-CART v3. I might stick with apache for now and use varnish - I just wanted to clarify what you were getting at.

Thanks for the reply, its a big help.

Also, do you think the full page cache addon is something that will be maintained for CS-CART or included in the core app at some point? I think its a great feature and you can't quite beat those 200ms page load times :)

Nathan

The full-page cache add-on was developed and is being maintained by CS-Cart team, aiming to provide the possibility of building highload solutions based on CS-Cart. However, it's provided as-is without any warranties. We'll continue maintaining it, however I'm not aware of including it into the core.

On the Nginx-related stuff: of course, Nginx serves static content better than Varnish does. In an ideal situation, Nginx should listen 80 port serving static content and proxying application-related requests to Varnish, which in its turn "talks" to another Nginx instance that is coupled to the php-fpm.

Ok, thanks...

Sounds good to me and its enough to get me up and running. I might revisit the architecture later on, once sales go through the roof!

Another change I am making to the original repo is to allow requests contain Auth as my staging site has basic Auth on it. I am just commenting out the lines in the VclGenerator.php file

Do you see any issues in regards to any other aspects of CS-CART. I am pretty sure that no where else in CS-CART Auth is used, but just wanted an expert opinion on this.

274 #if (req.http.Authorization) {

275 # return (pass);

276 #}

I think that if you comment those lines your requests containing Auth header can become cacheable which is not good IMO.

I see, do you mean from a security point of view?

I guess thats why I was asking if CS-CART uses auth anywhere else on the site. Would it apply to user logins? From my broad view I couldn't think of anywhere else in CS-CART that it would be used. But maybe I am wrong.

It's used at the REST API, but the REST API calls are disabled for caching in an another rule.

I see - thanks.. I think I will have a fork for production and staging... Appreciate it.

Last question :)

I have been getting errors in PHP from the Ride library when it tries to ban urls from the cache. Does the ride library support varnish 4.0 ban format? Or is that generated by the cscart full page cache addon code.

Cheers.

Hi there,

I have also setup the varnish cache using https by using pound to terminate the ssl connection. I am almost there, however I am having the issue where some blocks won't render on HTTPS. The main block in question is the cart content block. I haven't quite figured out how the ESI wrapper works, but I am assuming it is something to do with this.

Would there be anything obvious that would stop some blocks rendering on HTTPS? When I run it over HTTP, the block renders ok.

Almost there!

Thanks for your help,

Nathan

Figured it out...

https://github.com/magento/magento2/issues/3897

Just wanted to say thanks to the CS-CART team for pushing these types of addons. I realise they are not part of the official release, but they save a massive amount of time for when it comes to implementing varnish as part of your server setup.

I would recommend updating the default TTL for your varnish setup though. It depends on your content and traffic. But 90 seconds is probably not going to be enough time for users to benefit.

I think CS-CART's strength is in its easy customisation and hopefully further support for these 'edge' technologies for more advanced usage.

Hi there...

While I understand that the full page cache addon only supports one storefront. I found that it was causing an issue with accessing the theme editor of a non cached storefront. Looking at the varnish logs, the HTTP_HOST for https://www.aquarange.com.auwas set to https://www.bar-fridges-australia.com.au when the response came back from varnish which caused the theme editor load to fail.

I couldn't exactly track down where in the process that it was going wrong, but after removing varnish (and pound which I was using for SSL) from the setup, I could access the theme editor again on all store fronts.

Anyone else experience this?

Cheers,

Nathan

Will this add-on work with CS-Cart 4.4.1?

Will this add-on work with CS-Cart 4.4.1?

Same question, does this addon support 4.4.1 ?

Same question, new version: will this addon work with CS-Cart 4.4.2?

Hello guys,

Excuse me for such a late reply.

Full page cache add-on was out of priority focus for a while and we haven't tested it on a recent versions of CS-Cart.

However this is about to change. We're planning to continue improving this add-on and test it on a recent versions.

Stay tuned and contribute via pull requests! :)

Hello guys,

Excuse me for such a late reply.

Full page cache add-on was out of priority focus for a while and we haven't tested it on a recent versions of CS-Cart.

However this is about to change. We're planning to continue improving this add-on and test it on a recent versions.

Stay tuned and contribute via pull requests! :)

Perhaps a upgrade to varnish 5.0 & CS-Cart 4.4.3 / 4.4.4 ?