Several hints are available for tuning the performance

WORK-IN-PROGRESS

Performance impacts in general

• huge amount of items to lookup
• slow CPU
• less memory for to be used by OS for caching file system access
• slow disk read access
• slow disk write access (in case of item cache must be rebuilded)
• high parallel access e.g. caused by too small sync intervals

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 age of sync token

Option max_sync_token_age has default is 30 days

TODO: add recommendations for min/max

Caching method of item cache

(i) supported since 3.3.2, code optimized since 3.5.10

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 enabling use_mtime_and_size_for_item_cache replacing SHA256 (cached items will be rebuilded on first touch).

Precondition: file system supports mtime with ns resolution (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)

Location of caching folder

(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 either disk or even shared memory. Check following options

• filesystem_cache_folder
• use_cache_subfolder_for_item

Profiling

(i) supported since 3.5.10

Profiling per request

Enable "per_request" profiling analysis but suppress logging in case duration is below provided limits in second (example: 10)

Displays top X functions.

Logging of header and XML request are also enabled to be able to be replayed for further analysis.

profiling = per_request
profiling_per_request_min_duration = 10
profiling_per_request_header = True
profiling_per_request_xml = True
profiling_top_x_functions = 10

Attention: don't set on production system profiling_per_request_min_duration below several seconds!

Profiling per request method

Run mid-/longterm analysis by enabling "per_request_method" profiling.

Displays top X functions every 600 seconds per method.

profiling = per_request_method
profiling_per_request_method_interval = 600
profiling_top_x_functions = 10