This site has been archived and you can no longer log in or post new messages. For up-to-date community resources please visit ezplatform.com

eZ Community » Forums » eZ Publish 5 Platform » EZ5, frontend cache is never...
expandshrink

EZ5, frontend cache is never refreshed after publishing content from legacy admin

EZ5, frontend cache is never refreshed after publishing content from legacy admin

Wednesday 18 March 2015 2:48:40 pm - 17 replies

Hi there,

I'm currently using EzPublish 2014.11 (5.4) in clustering mode (2 back, 3 front), external varnish.

EZ5 clustering settings are set, Legacy clustering settings are set too.

Each time a content is published, front ez5 cache are never updated. I need to do a php ezpublish/console cache:clear --env=prod on each one !

Which is the best way to manage cluster settings to ensure that legacy backoffice refresh ez5 caches too ?

Doc is not enough revelant about this.

Modified on Thursday 19 March 2015 8:51:33 am by fod ger

Wednesday 18 March 2015 4:41:57 pm

Yeah, we would need a doc page for that.

Wednesday 18 March 2015 5:14:47 pm

Hi,

This is the links to the documentation page to enable the cluster :

For the stash cache configuration, move the default config in each of the environnement configuration file otherwise stash.cache.default.drivers will be set to [ FileSystem, Memcache ] instead of [ Memcache ] in production.

Modified on Wednesday 18 March 2015 5:15:17 pm by Open Wide

Thursday 19 March 2015 8:51:05 am

Hi Open,

Thanks for this reply, I saw we can use memcached with stash bundle.

I saw that EZ5 services are used into ezpcontentpublishingprocess.php, specially into publish() method.

But I'm afraid, it seems to generate only static cache.

Can you explain how using memcache with stash bundle will ensure to refresh EZ5 caches from legacy backoffice publishing ?

Thanks for.

 

PS : It could be useful to update docs about clustering cases.

PS2 : is it possible to use Redis with cluster instead of memcached ?

Modified on Thursday 19 March 2015 9:49:52 am by fod ger

Thursday 19 March 2015 10:52:41 am

OK I think I just understood, just need a confirmation.

Event listener is instanciated trought onBuildKernel method (eZBundle) and use persistenceCachePurger.

Thursday 19 March 2015 11:49:51 am

Hi,

maybe not all necerssary settings were in the ezpublish.yml?

Gist Link:

https://gist.github.com/anonymous/d09df366b169dd8283ab#file-gistfile1-yml

 

PS: Is there a "how to include a gist snippet within comments"? - I want to know which link I should enter in the text field.

Modified on Thursday 19 March 2015 11:56:15 am by Georg Franz

Thursday 19 March 2015 1:26:00 pm

Hi.

Multi-server requires that a network storage is used for stash, indeed. If Persistence Cache is local, it can't be cleared by a remote operation.

Open Wide's links are perfect.

Saturday 21 March 2015 7:50:56 pm

@Georg

You want to read this blog post that shows how to embed a gist in the share forums:

http://share.ez.no/blogs/ez/gist-arrives-on-share.ez.no

I hope this helps!

Cheers,
Heath

Tuesday 24 March 2015 12:13:32 am

Hi all,

there is a landing page for clustering for a few months now.

It mentions what Open Wide is mentioning, and some more.
In short you need to make sure to use shared cache solutions for persistence and HTTP cache for cluster to work correctly, otherwise it can't technically/physically/practically purge the cache.

see:  https://doc.ez.no/display/EZP/Clustering

Tuesday 24 March 2015 12:21:11 pm

Sounds good for me now, thx (I'll try to confirm). The constat also about ez5 / symfony part is css & js are not shared by NFS, they stay in local suspicious.gif Emoticon.

 

You should also update doc for external varnish configuration.

Use of symfony httpcache occures some trouble with external varnish because of friendsosyfmony or kernel (not sure) bundle which adds Vary header in response.

 

Finally, it could be useful to get typical clustering config (1 Bo, 1 or 2 FO) with and without use of internal SF reverse proxy.

 

N.B.: https://doc.ez.no/display/EZP/Legacy+DFS+cluster has been updated recently the 18/03/2015 just when I added my post :p.

Modified on Tuesday 24 March 2015 3:02:14 pm by fod ger

Saturday 28 March 2015 2:23:54 pm

Good to see that we can't hide, fod ger blunk.gif Emoticon

Turns out that André has added a couple lines, and that dspe has fixed the name of the flysystem adapter in an example, as can be seen in the history. But it is quite clear that the documentation must make it easier to find the whole thing and get the big picture.

Tuesday 31 March 2015 1:36:50 pm

Hi Bertrand,

Thx for feedback happy.gif Emoticon.

It's doesn't seem stable yet for me sad.gif Emoticon.

Some point about caches & ez5 are not clear, relations between type of caches and why css, js in EZ5 stack are not copied into NFS...

 

Should I disable symfony httcache to ensure like this ?

ezpublish:
     system:
     my_siteaccess:
         content:
             view_cache: false               
             ttl_cache: false
Thx again.

Modified on Tuesday 31 March 2015 1:43:06 pm by fod ger

Tuesday 31 March 2015 2:08:31 pm

css/js has from our side never been something we even considered to put on nfs.

NFS (or S3 or ..) for us is binary content from the content repository. Any code files is intended to be deployed by means of git/composer, and as you can also see in the composer post-update-cmd and post-install-cmd, running assetic dump and related commands are part of that workflow, on each server.

Modified on Tuesday 31 March 2015 2:19:01 pm by André R

Tuesday 31 March 2015 2:47:08 pm

Ok.

The bad is https://doc.ez.no/display/EZP/Persistence+cache+configuration doesn't work, I steel have have difference with cache synchronisation between servers.
And I follow example, All Memcached servers are reachable (telnet check). I tried also with only one server.
here my config on each server :
stash:
    caches:
        default:
            drivers: [ FileSystem, Memcache ]
            inMemory: true
            registerDoctrineAdapter: false
            Memcache:
                prefix_key: mysite_
                retry_timeout: 1
                servers:
                    - { server: 10.10.0.1.1, port: 11211 }
                    - { server: 10.10.0.1.2, port: 11211 }
                    - { server: 10.10.0.1.3, port: 11211 }

what's wrong ? I just needed again to delete ezpublish/cache/*. Boring.

Modified on Tuesday 31 March 2015 3:06:19 pm by fod ger

Tuesday 31 March 2015 4:05:19 pm

The problem is that you are still caching the cache on file system, you need to remove "FileSystem" when running with several servers. See the config example for memcached on the page you linked to if in doubt.

Modified on Tuesday 31 March 2015 4:06:39 pm by André R

Tuesday 31 March 2015 4:14:24 pm

Open Wide was wrong so ? I belived FileSystem was a security if loosing memcaches servers... thks

Modified on Tuesday 31 March 2015 4:20:30 pm by fod ger

Tuesday 31 March 2015 4:25:01 pm

Quote from fod ger :

Open Wide was wrong so ? I belived FileSystem was a security if loosing memcaches servers... thks

Yes, but based on what was written I don't think they implied what you write here at all, but I'll let them clarify what they meant with:

Quote from Open Wide :

otherwise stash.cache.default.drivers will be set to [ FileSystem, Memcache ] instead of [ Memcache ] in production.

Or was there additional discussions on this other places?

Tuesday 31 March 2015 4:42:47 pm

Ok it's was a misunderstanding. It seems to work perfectly for now.

expandshrink

You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu

Proudly Developed with from