Using the Caches of the GUI and the Portal Manager

For performance optimization purposes, both the editorial system (GUI) and the live server (PM) are provided with several caches. The dimension of these caches should be adapted to the server hardware used, particularly to its main memory.

The caches can be configured in the gui.xml and pm.xml files. A cache can be identified by its bean entry of the org.springframework.cache.ehcache.EhCacheFactoryBean class. If the following cache properties have not been set, the corresponding cache is not active. Each cache has the following configurable properties:

  • maxElementsInMemory
    The maximum number of elements kept in the cache simultaneously.
  • timeToIdle
    The time in seconds after which an unused element is removed from the cache. (0 for unlimited).
  • timeToLive
    The time in seconds an element may remain in the cache. After this time the element is removed from the cache (0 for unlimited).

The other cache properties should not be modified.

Live Server and Preview in the Editorial System

  • permissions
    The live read permissions can be cached to speed up access to them. Compared to cache elements for pages, for example, the cache elements are small and do not burden the system. In the editorial system, the timeToLive of the cache objects should not be chosen too large so that changes to the live read permissions are reflected promptly in the preview.
  • velocity
    Dynamic content is generated by the Velocity Template Engine erzeugt. To speed up this process, the parsed templates can be stored in the cache. Typically, no such cache is used in the editorial system to ensure that changes to files and layouts are always made visible.

Editorial System

In the editorial system, caches can be invoked for the following elements:

  • user
    The users of the editorial system. The number of elements should match the number of known users and the maximum number of users logged-in simultaneously.
  • groups
    The user groups in the editorial system. The number of cache elements should be adapted to the number of known groups.
  • live-groups
    The user groups available for assigning live read permissions. The number of cache elements should be adapted to the number of known groups.
  • attributes
    The fields used in file formats. The number of cache entries should be adapted to the total number of fields that were assigned to the most often used formats.
  • objClasses
    The file formats. The number of cache entries should be adapted to the number of file formats used most often.
  • channels
    The channels to which content can be assigned. In most cases very few channels exist. Therefore, the number of elements should correspond to or slightly exceed the number of channels defined in the CMS.
  • workflows
    The workflows. The number of cache elements can be set analogously to the number of elements for channels.
  • pages
    The pages opened in the editorial system. Theoretically, this number is unlimited and should not be decreased. The pages are removed from the cache after they have not been viewed in the browser for up to timeToIdle seconds.