I've got some questions about how Umbraco caches its XML if I may:
* I noticed that umbraco writes down a XML file which seems to contain all the XML for a given site, I guess this is used to prime a cache on app start up only? * Publishing a node will update the above file and the in memory cache? * Is the in memory cache one big doc or is it a doc per node? * Assume its just using .nets Cache opbject?
Reason for asking we want to create a lot of docs automagically over time but are worried about it slowing up the Cache or running out of memory, most of these docs are only for history sake and won't be accessed very often so no need for them to be in the Cache.
* Would start up be affected? * Is there a way to exclude a doc from the cache and simply get Umbraco to load it if needed? * Could we get around the Cache with GetNodeById? * Would a separate table be a better solution?
The cache holds all published nodes. If you are worried that you are going run out of memory because of the shear number of nodes I would look at your architecture to assess whether going with umbraco document nodes is the most effective way of dealing with your problem. No.1 is that if you have huge numbers of nodes your tree is going to slow down for a start (wont be as much of an issue once 4.1 is released). 2. if all those nodes are published the cache in memory is going to be larger.
The only way to exclude a node from cache is to unpublish it. if that is not an option because you need to still view that data I would probably go with a custom table use rewrites or usercontrols to pull that info in.
Peter that helps a lot. Separate table it is. Thanks for the insider info. I was indeed worried about memory size and speed of the cache. No need to have all the docs we wanted to create as nodes so will push them into another table and take it from there.
The xml file is a dump that's made async after the in-memory cache has been updated. The purpose is to make app warmup time as fast as possible (<1 sec).
A rule of thumb is that Umbraco scales up to 150.000 *published* documents (not counting media items) but we've had a PRO client who had 350.000 nodes before they got into trouble (it depends on the amount of properties and data on each node of course).
However, as Peter mentions you might get other issues before that. Umbraco is optimized for editorial content with a big overhead if you don't need stuff like versioning, flexible document models, etc. Especially with tabular data or huge article archives we usually recommend keeping them in separate tables.
Hi, i have a question say if we keep the node properties in a separate table, then we do a SQL Query to get the record and display it in a usercontrol macro. But what happens with the url? We won't get a pretty url instead we use querystring ?ID= Is there any way around this? Just a thought
Questions about Umbraco's XML Cache
I've got some questions about how Umbraco caches its XML if I may:
* I noticed that umbraco writes down a XML file which seems to contain all the XML for a given site, I guess this is used to prime a cache on app start up only?
* Publishing a node will update the above file and the in memory cache?
* Is the in memory cache one big doc or is it a doc per node?
* Assume its just using .nets Cache opbject?
Reason for asking we want to create a lot of docs automagically over time but are worried about it slowing up the Cache or running out of memory, most of these docs are only for history sake and won't be accessed very often so no need for them to be in the Cache.
* Would start up be affected?
* Is there a way to exclude a doc from the cache and simply get Umbraco to load it if needed?
* Could we get around the Cache with GetNodeById?
* Would a separate table be a better solution?
Cheers
Pete
The cache holds all published nodes. If you are worried that you are going run out of memory because of the shear number of nodes I would look at your architecture to assess whether going with umbraco document nodes is the most effective way of dealing with your problem. No.1 is that if you have huge numbers of nodes your tree is going to slow down for a start (wont be as much of an issue once 4.1 is released). 2. if all those nodes are published the cache in memory is going to be larger.
The only way to exclude a node from cache is to unpublish it. if that is not an option because you need to still view that data I would probably go with a custom table use rewrites or usercontrols to pull that info in.
Hope that helps.
Peter that helps a lot. Separate table it is. Thanks for the insider info. I was indeed worried about memory size and speed of the cache. No need to have all the docs we wanted to create as nodes so will push them into another table and take it from there.
Cheers
Pete
Peter is right and you're right too.
The xml file is a dump that's made async after the in-memory cache has been updated. The purpose is to make app warmup time as fast as possible (<1 sec).
A rule of thumb is that Umbraco scales up to 150.000 *published* documents (not counting media items) but we've had a PRO client who had 350.000 nodes before they got into trouble (it depends on the amount of properties and data on each node of course).
However, as Peter mentions you might get other issues before that. Umbraco is optimized for editorial content with a big overhead if you don't need stuff like versioning, flexible document models, etc. Especially with tabular data or huge article archives we usually recommend keeping them in separate tables.
Hi, i have a question say if we keep the node properties in a separate table, then we do a SQL Query to get the record and display it in a usercontrol macro. But what happens with the url? We won't get a pretty url instead we use querystring ?ID=
Is there any way around this? Just a thought
You could use the URL Rewriter feature of Umbraco to build up a pretty URL which would redirect off to your ?ID= page.
is working on a reply...