Jump to content

  • You cannot start a new topic
  • You cannot reply to this topic

Full Page Cache Addon Rate Topic   - - - - -

 
  • natewallis
  • Advanced Member
  • Members
  • Join Date: 11-Jan 13
  • 128 posts

Posted 04 July 2016 - 08:58 PM #1

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



 
  • abolshakov
  • Architect
  • CS-Cart Architects
  • Join Date: 20-Aug 14
  • 93 posts

Posted 05 July 2016 - 08:39 AM #2

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.


Alexander Bolshakov
CS-Cart Architect Team


 
  • natewallis
  • Advanced Member
  • Members
  • Join Date: 11-Jan 13
  • 128 posts

Posted 05 July 2016 - 05:21 PM #3

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



 
  • abolshakov
  • Architect
  • CS-Cart Architects
  • Join Date: 20-Aug 14
  • 93 posts

Posted 05 July 2016 - 05:34 PM #4

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.


Alexander Bolshakov
CS-Cart Architect Team


 
  • natewallis
  • Advanced Member
  • Members
  • Join Date: 11-Jan 13
  • 128 posts

Posted 05 July 2016 - 05:37 PM #5

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!



 
  • natewallis
  • Advanced Member
  • Members
  • Join Date: 11-Jan 13
  • 128 posts

Posted 05 July 2016 - 07:36 PM #6

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     #}



 
  • abolshakov
  • Architect
  • CS-Cart Architects
  • Join Date: 20-Aug 14
  • 93 posts

Posted 05 July 2016 - 07:38 PM #7

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


Alexander Bolshakov
CS-Cart Architect Team


 
  • natewallis
  • Advanced Member
  • Members
  • Join Date: 11-Jan 13
  • 128 posts

Posted 05 July 2016 - 07:42 PM #8

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.     



 
  • abolshakov
  • Architect
  • CS-Cart Architects
  • Join Date: 20-Aug 14
  • 93 posts

Posted 05 July 2016 - 07:44 PM #9

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


Alexander Bolshakov
CS-Cart Architect Team


 
  • natewallis
  • Advanced Member
  • Members
  • Join Date: 11-Jan 13
  • 128 posts

Posted 05 July 2016 - 07:45 PM #10

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



 
  • natewallis
  • Advanced Member
  • Members
  • Join Date: 11-Jan 13
  • 128 posts

Posted 05 July 2016 - 08:12 PM #11

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. 



 
  • natewallis
  • Advanced Member
  • Members
  • Join Date: 11-Jan 13
  • 128 posts

Posted 06 July 2016 - 07:25 PM #12

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



 
  • natewallis
  • Advanced Member
  • Members
  • Join Date: 11-Jan 13
  • 128 posts

Posted 06 July 2016 - 08:06 PM #13

Figured it out... 

 

https://github.com/m...to2/issues/3897



 
  • natewallis
  • Advanced Member
  • Members
  • Join Date: 11-Jan 13
  • 128 posts

Posted 08 July 2016 - 05:24 AM #14

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.



 
  • natewallis
  • Advanced Member
  • Members
  • Join Date: 11-Jan 13
  • 128 posts

Posted 31 August 2016 - 11:57 PM #15

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-frid...ustralia.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



 
  • Ayokay
  • Junior Member
  • Members
  • Join Date: 12-Apr 11
  • 29 posts

Posted 15 November 2016 - 05:06 PM #16

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



 
  • mazter
  • Senior Member
  • Members
  • Join Date: 04-Apr 12
  • 228 posts

Posted 20 November 2016 - 09:44 AM #17

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

 

Same question, does this addon support 4.4.1 ?



 
  • Ayokay
  • Junior Member
  • Members
  • Join Date: 12-Apr 11
  • 29 posts

Posted 22 December 2016 - 07:18 PM #18

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



 
  • abolshakov
  • Architect
  • CS-Cart Architects
  • Join Date: 20-Aug 14
  • 93 posts

Posted 02 February 2017 - 09:25 PM #19

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! :)


Alexander Bolshakov
CS-Cart Architect Team


 
  • poppedweb
  • Advanced Member
  • Members
  • Join Date: 02-Aug 16
  • 146 posts

Posted 04 February 2017 - 01:19 PM #20

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 ?