# content
The littleFedi caching system is configurable and adaptable. Caching helps immensely, and for this very reason, you can choose to keep the cache "warm."

By default, if enabled (which makes a lot of sense on slow hardware), the system tracks user activity over the last n minutes (15 by default). For those minutes following the last interaction with the system, the cache will be kept warm.

Does a new post arrive in the timeline? It gets processed and cached, immediately (and partially) re-processing the timeline cache. The user will see it immediately in the timeline.

On a Raspberry Pi Zero W running NetBSD on an SD card, this means dropping the timeline generation time from about 5 seconds down to roughly 0.20 seconds.

After 15 minutes of inactivity from the user, the system will stop keeping the cache warm, reducing the CPU load to nearly zero (provided you aren't doing local processing of remote images, of course - which is also configurable). Upon the user's first visit, it will take a few extra seconds (cold cache), but from that moment on, everything will be almost instantaneous.

There's also a cache for the federation activities (a boost won't cause constant reprocessing of that post), but this isn't that different from other implementations' approach.

#littleFedi #Fediverse #OwnYourData

# contentMap.en
The littleFedi caching system is configurable and adaptable. Caching helps immensely, and for this very reason, you can choose to keep the cache "warm."

By default, if enabled (which makes a lot of sense on slow hardware), the system tracks user activity over the last n minutes (15 by default). For those minutes following the last interaction with the system, the cache will be kept warm.

Does a new post arrive in the timeline? It gets processed and cached, immediately (and partially) re-processing the timeline cache. The user will see it immediately in the timeline.

On a Raspberry Pi Zero W running NetBSD on an SD card, this means dropping the timeline generation time from about 5 seconds down to roughly 0.20 seconds.

After 15 minutes of inactivity from the user, the system will stop keeping the cache warm, reducing the CPU load to nearly zero (provided you aren't doing local processing of remote images, of course - which is also configurable). Upon the user's first visit, it will take a few extra seconds (cold cache), but from that moment on, everything will be almost instantaneous.

There's also a cache for the federation activities (a boost won't cause constant reprocessing of that post), but this isn't that different from other implementations' approach.

#littleFedi #Fediverse #OwnYourData

# source.content
The  **littleFedi**  caching system is configurable and adaptable. Caching helps immensely, and for this very reason, you can choose to keep the cache  **"warm."**

By default, if enabled (which makes a lot of sense on slow hardware), the system tracks user activity over the last  *n* minutes (**15 by default**). For those minutes following the last interaction with the system, the cache will be kept warm.

Does a new post arrive in the timeline? It gets processed and cached, immediately (and partially) re-processing the timeline cache. The user will see it immediately in the timeline.
    
On a Raspberry Pi Zero W running NetBSD on an SD card, this means dropping the timeline generation time from about  **5 seconds**  down to roughly  **0.20 seconds**.
    
After 15 minutes of inactivity from the user, the system will stop keeping the cache warm, reducing the CPU load to  **nearly zero**  (provided you aren't doing local processing of remote images, of course - which is also configurable). Upon the user's first visit, it will take a few extra seconds (**cold cache**), but from that moment on, everything will be  **almost instantaneous**.

There's also a cache for the federation activities (a boost won't cause constant reprocessing of that post), but this isn't that different from other implementations' approach.

#littleFedi #Fediverse #OwnYourData