Caching
Results of expensive or slow operations can be cached to speed up Nextcloud and its apps.
Types of caches
Nextcloud offers in-memory, local and distributed caches. The caching back-end (APCu, Redis, Memcached) is configurable.
For single server setups, admins typically only configure one type of cache. Larger installations can have two types of cache. The Nextcloud API lets you pick a cache type. The following table tries to highlight the main advantages and disadvantages of each type.
In-memory cache |
Local cache |
Distributed cache |
|
|---|---|---|---|
Latency |
Low |
Low |
High |
Data scope |
Same process |
Application server |
Full cluster |
Expiration |
End of process |
TTL reached |
TTL reached |
For scalability it should be preferred to use local caches. A local cache has to be populated on each application server, but avoids creating a bottleneck of too much traffic on the distributed cache. A distributed cache is most useful for data that has to be synchronized across the full Nextcloud cluster.
In-memory cache
The OCP\Cache\CappedMemoryCache class is an in-memory cache that can be used like an array:
A cache instance can also be built by the cache factory. This approach allows mocking the injected factory for finer control during :ref:`unit testing<testing-php>`:
Local cache
A local cache instance can be acquired through the \OCP\ICacheFactory service. The factory can be injected:
Distributed cache
A distributed cache instance can be acquired through the \OCP\ICacheFactory service. The factory can be injected: