Differences
This shows you the differences between two versions of the page.
Next revision | Previous revisionNext revisionBoth sides next revision | ||
72:cms_prefetch [2018/07/17 13:19] – created bkkr | 72:cms_prefetch [2020/10/21 12:39] – [CMS Prefetch Configuration] twn | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | Configure the Stages Server | + | [[: |
- | ====== CMS Prefetch Configuration | + | ====== CMS Prefetch Configuration ====== |
The CMS prefetch is a Stages system service. It ensures that Stages displays up to date information of documents that are managed by an external configuration management system (CMS). Therefore the CMS prefetch is scheduled periodically to retrieve the latest revision information for all documents of active projects. | The CMS prefetch is a Stages system service. It ensures that Stages displays up to date information of documents that are managed by an external configuration management system (CMS). Therefore the CMS prefetch is scheduled periodically to retrieve the latest revision information for all documents of active projects. | ||
Line 8: | Line 8: | ||
=== Configuration of the CMS Prefetch === | === Configuration of the CMS Prefetch === | ||
- | The default configuration of the CMS prefetch is found in '' | + | The default configuration of the CMS prefetch is found in <font inherit/ |
< | < | ||
- | <pkit-config> | + | <stages-config> |
< | < | ||
Line 18: | Line 18: | ||
< | < | ||
< | < | ||
- | < | + | < |
- | value=" | + | |
</ | </ | ||
< | < | ||
- | </pkit-config> | + | </stages-config> |
</ | </ | ||
A more detailed description of these properties can be found in the following table: | A more detailed description of these properties can be found in the following table: | ||
- | ^Property | + | |==== Property |
- | |cms.prefetch.activated| \\ In case no configuration management system is configured the prefetch service can be completely deactivated. | + | |
- | \\ Default = true \\ | + | |==== Description ==== |
- | | | + | |
- | |cms.cache.refreshIntervalInMinutes| \\ A new prefetch run will be started after this period of time. (In case of a too short interval it will be delayed until the previous run has finished) \\ | + | |
- | \\ Default = 60 \\ | ||
| | | | ||
- | |cms.cache. | + | | \\ |
+ | | ||
+ | In case no configuration management system is configured the prefetch service can be completely deactivated. \\ | ||
+ | \\ | ||
+ | | ||
+ | | \\ | ||
+ | cms.cache.refreshIntervalInMinutes| \\ | ||
+ | A new prefetch | ||
+ | \\ | ||
+ | | ||
+ | | \\ | ||
+ | | ||
+ | In case the prefetch service produces too much CPU load on the Stages server or on the CMS, it can be forced to pause for some time. This will of course lead to longer running prefetches. \\ | ||
+ | \\ | ||
+ | | ||
+ | | \\ | ||
+ | | ||
+ | In case the prefetch does not finish its work within the specified referesh interval, the amount of worker threads utilized by the prefetch can be increased. This will lead to additional CPU load and load on the CMS. \\ | ||
+ | \\ | ||
+ | | ||
+ | | \\ | ||
+ | | ||
+ | | ||
+ | \\ | ||
+ | | ||
+ | | \\ | ||
+ | | ||
+ | Where < | ||
+ | CMS types specified | ||
+ | used by some of the available Strategies. E.g. CMSTypeStrategy. It can be used to restrict the amount of parallel tasks that work on the same type of CMS. \\ | ||
+ | \\ | ||
+ | | ||
+ | | \\ | ||
+ | | ||
+ | In case this property exists in config.xml, scheduling of the initial prefetch run will be delayed until the configured hour of the day. Valid values are (0-23). E.g. for 22 the first prefetch run will be delayed to 22:00. It has to be ensured that the Stages service is up and running at this timepoint. If this property does not exist the prefetch will start directly after starting the Stages service. \\ | ||
+ | \\ | ||
+ | | ||
- | \\ Default | + | === Strategies === |
- | | | + | |
- | |cms.prefetch.sleepMillisBetweenDocuments| \\ In case the prefetch service produces too much CPU load on the Stages server or on the CMS, it can be forced to pause for some time. This will of course lead to longer running prefetches. \\ | + | |
- | \\ Default = 0 \\ | + | The following |
- | | | + | |
- | |cms.prefetch.workersCount| \\ In case the prefetch does not finish its work within the specified referesh interval, the amount of worker threads utilized by the prefetch can be increased. This will lead to additional CPU load and load on the CMS. \\ | + | |
- | \\ Default = 1 \\ | + | //Classic all documents available//< |
- | | | + | |
- | |cms.prefetch.strategy.class| \\ Specifies the strategy implementation to use to update the document revision information. \\ | + | |
- | \\ Default: de.methodpark.pkit.cms. prefetch.ClassicAllDocumentsStrategy \\ | + | class=AllDocumentsStrategy |
- | | | + | |
- | |cms.prefetch.maxParallelTasks.< | + | |
- | \\ Default = 1 \\ | + | </ |
- | | | + | |
- | |cms.prefetch.initialStart.hourOfDay| \\ In case this property exists in PKitConfig.xml, | + | |
- | \\ Default: | + | This strategy ignores the maxParallelTasks properties. (cms.prefetch.maxParallelTasks.<CMSType>) It is the default strategy. In case of a single worker thread the documents are prefetched sequentially. In case of multiple worker threads the prefetch of single documents is arbitrarily distributed among all workers. |
- | \\ \\ | + | //Prefetch by CMS type strategy// |
- | | | + | < |
+ | class=CMSTypeStrategy | ||
+ | |||
+ | </ | ||
+ | |||
+ | This strategy allows more detailed configuration on the distribution of prefetches dependent on the type of CMS the document is hosted. | ||
+ | |||
+ | cms.prefetch.maxParallelTasks. allows to specify the maximum number of workers that are allowed to process documents of that CMS type. This is useful in case different CMS types are used by one Stages deployment and the CM systems have very different performance characteristics. So it is e.g. possible to specify that there is only one worker for SVN and all other workers should be used for Integrity. This example would need the following configuration: | ||
+ | |||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | | ||
+ | |||
+ | < | ||
+ | </ | ||
+ | |||
+ | < | ||
+ | </ | ||
+ | |||
+ | </ | ||
+ | |||
+ | === Cache Persistence === | ||
+ | |||
+ | Stages caches two different levels of information regarding files in external configuration management systems. It collects infomation about the folder structure of a CMS and the files contained within these folders. This information is then used for displaying document information such as the version or state of a file. | ||
+ | |||
+ | These caches are persisted in the file system on the application server that runs Stages. | ||
+ | |||
+ | The cache size has a fixed size but will be configurable from Version 7.4.6.1, 7.5.2.1 and above. | ||
\\ | \\ | ||