cancel
Showing results for 
Search instead for 
Did you mean: 

Separated Share front ends

t16
Champ in-the-making
Champ in-the-making
We have our share front ends running in a separate tier to the main alfresco repo servers.

Are there any cache settings we can apply to share to speed things up?

I notice there are a bunch of cache settings on the alfresco repo boxes, but I cannot for the life of me find ANY share front end cache settings anywhere!!

Can one of the experts on this please offer some guidance?

Also when it comes to the caching on the Alfresco repo teir, would we see better performance by setting ALL the caches to "Invalidating" rather than "fully-distributed" ?

I presume in fully distributed each repo server has to query the other one for content thats cached on the other repo boxes?


Many many thanks if any one can help or comment.

Mrogers, I am hoping your expertise might be able to weigh in here!!

2 REPLIES 2

afaust
Legendary Innovator
Legendary Innovator
Hello,

there isn't much that is cached in Share tier - basically just the dynamic Surf view model fragments for dashboards and sites. As a result, there is little need for cache setting modifications. Settings can be found in Surf files, e.g. <a href="https://github.com/Alfresco/community-edition/blob/e0c6c4088320113db82e16ca5e3261aa321ec26d/projects...">spring-surf-config.xml</a> and <a href="https://github.com/Alfresco/community-edition/blob/e0c6c4088320113db82e16ca5e3261aa321ec26d/projects...">spring-surf-model-context.xml</a>.

Setting every cache to invalidating will break some functionality that relies on fully distributed caching, specifically authentication tickets and potentially some kind of transient locks not persisted in the database. "Invalidating" mode also does not mean that every cluster node maintains a full copy of cluster data and does not have to query for data - the cluster nodes will end up having only the data they already accessed in caches and querying the database instead of other cluster nodes. It is assumed that cluster communication to obtain cached objects is faster than re-executing the entire database query and post-processing.

Regards
Axel

t16
Champ in-the-making
Champ in-the-making
Ahh ok thanks for the reply.

I think we will leave the cache settings with respect to the invalidating and fully-clustered settings at their default for now.

Thank you for the detailed explanation, its always great to learn the nuts and bolts.