Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
72:cms_prefetch [2018/07/17 13:20] – [CMS Prefetch Configuration] bkkr | 72:cms_prefetch [2018/07/17 13:33] – bkkr | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | Configure the Stages Server | + | [[: |
====== CMS Prefetch Configuration ====== | ====== CMS Prefetch Configuration ====== | ||
Line 27: | Line 27: | ||
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^Description| | + | TBD |
- | |cms.prefetch.activated| | + | |
- | In case no configuration management system is configured the prefetch service can be completely deactivated. \\ | + | |
- | \\ | + | |
- | | + | |
- | |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) \\ | + | |
- | \\ | + | |
- | | + | |
- | |cms.cache. lastAccessIntervalForActiveProjectsInDays| | + | |
- | The prefetch will only update documents that are referenced by projects that were used (browsed) within the specified time frame. \\ | + | |
- | \\ | + | |
- | | + | |
- | |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. \\ | + | |
- | \\ | + | |
- | | + | |
- | |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. \\ | + | |
- | \\ | + | |
- | | + | |
- | |cms.prefetch.strategy.class| | + | |
- | | + | |
- | \\ | + | |
- | | + | |
- | |cms.prefetch.maxParallelTasks.< | + | |
- | Where < | + | |
- | \\ | + | |
- | | + | |
- | |cms.prefetch.initialStart.hourOfDay| | + | |
- | In case this property exists in PKitConfig.xml, | + | |
- | \\ | + | |
- | | + | |
- | | | + | |
- | \\ | + | === Strategies === |
+ | |||
+ | The following prefetch strategies are currently available. | ||
+ | |||
+ | //Classic all documents available// | ||
+ | < | ||
+ | class=de.methodpark.pkit.cms.prefetch.ClassicAllDocumentsStrategy | ||
+ | </ | ||
+ | |||
+ | This strategy ignores the maxParallelTasks properties. (cms.prefetch.maxParallelTasks.< | ||
+ | |||
+ | //Prefetch by CMS type strategy// | ||
+ | < | ||
+ | class=de.methodpark.pkit.cms.prefetch.PrefetchByCMSTypeStrategy | ||
+ | </ | ||
+ | |||
+ | 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 - by default - persisted in the file system on the application server that runs Stages. However the administrator may configure these caches to be stored within a relational Database. This increases cache performance significantly. | ||
+ | |||
+ | The configuration of this is done in the Stages configuration file ''< | ||
+ | |||
+ | Each cache requires its own configuration and its own database. An example configuration for both MySQL and Oracle database servers can be found within the file. | ||
+ | |||
+ | //Note//: After changing the cache persistence settings, the Stages configuration has to be updated (''< | ||