Hi All,
I'm implementing dispatcher for the first time and I have a question on statfilefileslevel and statfile.
What are best practices to use this configuration in dispatcher.
Thanks,
Aruna
Solved! Go to Solution.
Hi @Anny0505
/statfileslevel
You may use /statfileslevel property of the dispatcher configuration file to selectively invalidate cached files according to their path. There are some rules for /statfileslevel property mechanism:
1. Dispatcher creates .stat files in each folder from the docroot folder down to the level that you specify. The docroot folder is level 0.
2. When a file is updated dispatcher locates the folder on the file path that is at the statfileslevel and invalidates all files below that folder.
3. If level of the updated file is less than statfileslevel then all files in such folder are invalidated. Files below that folder are not invalidated.
4. When a file is updated then all files from file folder up to the root level inclusive will be invalidated.
For a better understanding of the /statfileslevel rules let’s consider a couple of examples.
- statefile lelvel 0 - A single .stat file will be created at the root of the cache directory.
/.stat
- statefile lelvel 1 - .stat file at root of the cache and under each direct chile directory.
/.stat
/content/.stat
- statefile level 2 - .stat file at root of cache and under each direct child directory and each of their direct child directories:
/.stat
/content/.stat
/content/foo/.stat
/content/bar/.stat
let's see the default /statfileslevel “0” looks like -
- There is only one stat-file at the root folder of our docroot/cache root.
- The scope of responsibility of that stat-file is all file-tree under htdocs.
- If any file from this tree has older modification time then stat-file modification time then dispatcher consider such file is invalidated.
- statfileslevel = 0 is only for learning demo. It is not recommended to use 0 in the live production environment as it may end up flushing all cache every time any file gets modified.
Now let's set /statfileslevel “4” more realistic scenario, and see how the invalidation works - :
- There will be stat files at all levels from 0 (root) to 4 inclusive.
- There will be stat files at 5 levels (0 to 4) of the folder structure.
Stat-files at levels less than 4 have the scope of responsibility with the only directory with this stat-file.
- That means if stat-file inside content/we-retail/en folder is newer than any file from this folder then such file is invalidated but the validation of all files from all other folders is determined by other stat-files.
- Stat-files at the level with a value of statfileslevel property (level 4 in our case) only have the scope of responsibility with all underlying tree which begins from a folder with this stat-file and expands down to lower levels of the file tree.
That means that if stat-file inside content/we-retail/en/products folder has modification time newer than any file from underlying tree including products folder then dispatcher considers such file is invalidated. Validation of all files which is not located in this file tree is determined by other stat-files.
Stat-files at the level with a value of statfileslevel property (level 4 in our case) only have the scope of responsibility with all underlying tree which begins from folder with this stat-file and expands down to lower levels of the file tree.
That means that if stat-file inside content/we-retail/en/products folder has modification time newer than any file from the underlying tree including products folder then dispatcher considers such file is invalidated. Validation of all files which is not located in this file tree is determined by other stat-files.
Regards
Santosh
The statfilefileslevel level 0 invalidate all the contentent irrespective of the content hierarcy on every activation/deactivation - this is not recommended as will impact the performance
My recommendation is to start with 2 or 3 based on your content structure and validate different scenarios - how the content activations impacting the cache, and identify the optimal statfilefileslevel value.
Additinaly you can use TTL based cache invalidation to invalidate the cache for specific scenarios e.g Sitemaps - https://helpx.adobe.com/experience-manager/kb/optimizing-the-dispatcher-cache.html
Also, you can use Dispatcher Flush Rules - https://adobe-consulting-services.github.io/acs-aem-commons/features/dispatcher-flush-rules/index.ht... to flush the depndent content from dispatcher cache.
Regards
Albin I
Hi @Anny0505
/statfileslevel
You may use /statfileslevel property of the dispatcher configuration file to selectively invalidate cached files according to their path. There are some rules for /statfileslevel property mechanism:
1. Dispatcher creates .stat files in each folder from the docroot folder down to the level that you specify. The docroot folder is level 0.
2. When a file is updated dispatcher locates the folder on the file path that is at the statfileslevel and invalidates all files below that folder.
3. If level of the updated file is less than statfileslevel then all files in such folder are invalidated. Files below that folder are not invalidated.
4. When a file is updated then all files from file folder up to the root level inclusive will be invalidated.
For a better understanding of the /statfileslevel rules let’s consider a couple of examples.
- statefile lelvel 0 - A single .stat file will be created at the root of the cache directory.
/.stat
- statefile lelvel 1 - .stat file at root of the cache and under each direct chile directory.
/.stat
/content/.stat
- statefile level 2 - .stat file at root of cache and under each direct child directory and each of their direct child directories:
/.stat
/content/.stat
/content/foo/.stat
/content/bar/.stat
let's see the default /statfileslevel “0” looks like -
- There is only one stat-file at the root folder of our docroot/cache root.
- The scope of responsibility of that stat-file is all file-tree under htdocs.
- If any file from this tree has older modification time then stat-file modification time then dispatcher consider such file is invalidated.
- statfileslevel = 0 is only for learning demo. It is not recommended to use 0 in the live production environment as it may end up flushing all cache every time any file gets modified.
Now let's set /statfileslevel “4” more realistic scenario, and see how the invalidation works - :
- There will be stat files at all levels from 0 (root) to 4 inclusive.
- There will be stat files at 5 levels (0 to 4) of the folder structure.
Stat-files at levels less than 4 have the scope of responsibility with the only directory with this stat-file.
- That means if stat-file inside content/we-retail/en folder is newer than any file from this folder then such file is invalidated but the validation of all files from all other folders is determined by other stat-files.
- Stat-files at the level with a value of statfileslevel property (level 4 in our case) only have the scope of responsibility with all underlying tree which begins from a folder with this stat-file and expands down to lower levels of the file tree.
That means that if stat-file inside content/we-retail/en/products folder has modification time newer than any file from underlying tree including products folder then dispatcher considers such file is invalidated. Validation of all files which is not located in this file tree is determined by other stat-files.
Stat-files at the level with a value of statfileslevel property (level 4 in our case) only have the scope of responsibility with all underlying tree which begins from folder with this stat-file and expands down to lower levels of the file tree.
That means that if stat-file inside content/we-retail/en/products folder has modification time newer than any file from the underlying tree including products folder then dispatcher considers such file is invalidated. Validation of all files which is not located in this file tree is determined by other stat-files.
Regards
Santosh
Views
Likes
Replies