Performance tuning

Several hints are available for tuning the performance

WORK-IN-PROGRESS

Filesystem

Recommendations

• journalling file system like ext4 or xfs
• in case of activation of use_mtime_and_size_for_item_cache a filesystem supporting mtime with ns granularity, e.g. xfs
• active-passive setup can use GlusterFS or NFS share, use of use_mtime_and_size_for_item_cache can be considered to keep the cache on a local node

Radicale configuration

Storage

type

type = multifilesystem_nolock turns from using lock mechanism on operating system / file system level to be handled internally by "radicale"

DO NOT USE on a shared filesystem in combination with a clustered "radicale" application as there is no locking synchronization currently existing between cluster members beside using lock files on filesystem.

max_sync_token_age

Default is 30 days

TODO: add recommendations for min/max

use_mtime_and_size_for_item_cache

(i) supported since 3.3.2

In case collections with higher amount of items it can be that PROPFIND and REPORT requests are slow and even PUT requests take some time. In this case consider change of caching method.

Precondition: file system supports mtime with ns proper (us is potentially also still enough, ms can turn risky)

Background: it changes the cache content verification from SHA256(item) to filesystem metadata lookup mtime(item)+size(item)

filesystem_cache_folder + use_cache_subfolder_for_item

(i) supported since 3.3.2

In case collections are stored on a network filesystem, e.g. NFS or GlusterFS it can make sense to keep the cache on local node.