Umbraco 4.7.2.497... XmlContentCheckForDiskChanges - noticed new tag in UmbracoSettings.config
So we now have...
{!-- Enable / disable xml content cache --}
{XmlCacheEnabled}True{/XmlCacheEnabled}
{!-- Update disk cache every time content has changed --}
{ContinouslyUpdateXmlDiskCache}True{/ContinouslyUpdateXmlDiskCache}
{!-- Update in-memory cache if xml file is changed --}
{XmlContentCheckForDiskChanges}False{/XmlContentCheckForDiskChanges}
Is this the answer to my prayers.. where by our hosting is a clustered environment with a single data source, but no published ip's/dns to allow distributed calls..
If I set XmlContentCheckForDiskChanges = True will that mean an update on any node on the cluster causing a change to umbraco.config will fire on the other nodes a reload of the in memory xml.
Would anyone also shed any light on how these 3 settings interact with one another, if indeed they do?
I would also like to know what the new XmlContentCheckForDiskChanges setting is for. I did a google search and came up with nothing. I set this value to true in our production environment which has 2 servers load balanced and the sites would go down every couple hours. Once we set it to false we were ok.
Looking at Codeplex it tells Umbraco to check for changes to the umbraco.config file stored on disk and update the XML cache in memory when a change occurs.
I'm looking at potentially using this to change the way my load-balanced sites work, where all servers share the same files using a SAN, and turn off distributed calls which appear to cause site issues when under high-load and regular publish events.
basically u4.7.2 in a medium trust environment... the move document seems to call out to rebuild the lucerne/examine index and as that isn't supported in medium trust in u4.7.2 it caused crashes... sowe had to revert to disabling the xmlcache and forcing all calls to the db ;-(
with 4.8 stable and lucerne/examine updated to support medium trust we hope to revisit the chechxmlcache at some point in the near future
Ok, I have no knowledge if Medium Trust applies to our server setup.
At least after a couple of hours of testing with these new settings everything seems to work better than before. We have no errors in the umbraco log as we had before with failing distributed calls and therefore nodes can be published without problem.
One can wonder what will happen with umbraco.config if one of our three servers is temporarily down and then starts up again. We will have to wait and see.
I think the idea here is that you have a centralised file storage... with 3 webserver instances... so there is only ever one umbraco.config file.. and in your case if a server went down then when it came back up the app should restart and reload the umbraco.config from the cerntralised file anyway?
Right now umbraco.config is located in each web servers App_Data folder but all of umbraco:s files including umbraco.config is replicated with DFS. If we were to centralize umbraco.config in only one location we would lose one aspect of the load balancing.
I guess the DFS works in that way that it tries to synchronize all files when a failing server is started again. In that case we would be safe with always intact access to the generated umbraco.config.
our clustered cloud host has a single data store... with multiple iis instances hooked into it.. so should be well suited to the XmlContentCheckForDiskChanges ;-) here's hoping.
Umbraco 4.7.2.497... XmlContentCheckForDiskChanges - noticed new tag in UmbracoSettings.config
So we now have...
{!-- Enable / disable xml content cache --} {XmlCacheEnabled}True{/XmlCacheEnabled} {!-- Update disk cache every time content has changed --} {ContinouslyUpdateXmlDiskCache}True{/ContinouslyUpdateXmlDiskCache} {!-- Update in-memory cache if xml file is changed --} {XmlContentCheckForDiskChanges}False{/XmlContentCheckForDiskChanges}Is this the answer to my prayers.. where by our hosting is a clustered environment with a single data source, but no published ip's/dns to allow distributed calls..
If I set XmlContentCheckForDiskChanges = True will that mean an update on any node on the cluster causing a change to umbraco.config will fire on the other nodes a reload of the in memory xml.
Would anyone also shed any light on how these 3 settings interact with one another, if indeed they do?
I would also like to know what the new XmlContentCheckForDiskChanges setting is for. I did a google search and came up with nothing. I set this value to true in our production environment which has 2 servers load balanced and the sites would go down every couple hours. Once we set it to false we were ok.
Looking at Codeplex it tells Umbraco to check for changes to the umbraco.config file stored on disk and update the XML cache in memory when a change occurs.
See: http://umbraco.codeplex.com/workitem/30722
I'm looking at potentially using this to change the way my load-balanced sites work, where all servers share the same files using a SAN, and turn off distributed calls which appear to cause site issues when under high-load and regular publish events.
How did this work out for you?
We have also experienced problems with umbraco.config getting out of sync when publishing nodes in a DFS load balanced environment (http://our.umbraco.org/forum/getting-started/installing-umbraco/32906-Umbraco-in-load-balanced-environments-in-conjunction-with-DFS). I have just turned off Umbraco:s distributed calls but noticed that the XML cache wasn't updated when publishing content from one of the load balanced servers. This setting may be the key for us as well.
We weren't able to use it in the end...
basically u4.7.2 in a medium trust environment... the move document seems to call out to rebuild the lucerne/examine index and as that isn't supported in medium trust in u4.7.2 it caused crashes... sowe had to revert to disabling the xmlcache and forcing all calls to the db ;-(
with 4.8 stable and lucerne/examine updated to support medium trust we hope to revisit the chechxmlcache at some point in the near future
Sorry I can't help more.
Ok, I have no knowledge if Medium Trust applies to our server setup.
At least after a couple of hours of testing with these new settings everything seems to work better than before. We have no errors in the umbraco log as we had before with failing distributed calls and therefore nodes can be published without problem.
One can wonder what will happen with umbraco.config if one of our three servers is temporarily down and then starts up again. We will have to wait and see.
I think the idea here is that you have a centralised file storage... with 3 webserver instances... so there is only ever one umbraco.config file.. and in your case if a server went down then when it came back up the app should restart and reload the umbraco.config from the cerntralised file anyway?
Right now umbraco.config is located in each web servers App_Data folder but all of umbraco:s files including umbraco.config is replicated with DFS. If we were to centralize umbraco.config in only one location we would lose one aspect of the load balancing.
I guess the DFS works in that way that it tries to synchronize all files when a failing server is started again. In that case we would be safe with always intact access to the generated umbraco.config.
our clustered cloud host has a single data store... with multiple iis instances hooked into it.. so should be well suited to the XmlContentCheckForDiskChanges ;-) here's hoping.
is working on a reply...