PHPackages                             sandstorm/optimizedrediscachebackend - PHPackages - PHPackages  [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register)

1. [Directory](/)
2. /
3. [Caching](/categories/caching)
4. /
5. sandstorm/optimizedrediscachebackend

AbandonedArchivedNeos-package[Caching](/categories/caching)

sandstorm/optimizedrediscachebackend
====================================

1.1.5(4y ago)686.1k↓50%9[1 issues](https://github.com/sandstorm/OptimizedRedisCacheBackend/issues)MITPHP

Since Sep 26Pushed 3y ago10 watchersCompare

[ Source](https://github.com/sandstorm/OptimizedRedisCacheBackend)[ Packagist](https://packagist.org/packages/sandstorm/optimizedrediscachebackend)[ RSS](/packages/sandstorm-optimizedrediscachebackend/feed)WikiDiscussions master Synced 1mo ago

READMEChangelog (10)Dependencies (1)Versions (12)Used By (0)

Optimized Redis Cache Backend
=============================

[](#optimized-redis-cache-backend)

OBSOLETE Since Neos 8.0
-----------------------

[](#obsolete-since-neos-80)

NOTE: OptimizedRedisCacheBackend is OBSOLETE for Neos 8.0 and newer, as its functionality has been [integrated into the core](https://github.com/neos/flow-development-collection/pull/2721), and improved further on. Thanks Sebastian Helzle and everybody involved for that :-) :-)

### How to migrate from OptimizedRedisCacheBackend to Neos 8.x

[](#how-to-migrate-from-optimizedrediscachebackend-to-neos-8x)

The functionality of `Sandstorm\OptimizedRedisCacheBackend\OptimizedRedisCacheBackend` has been integrated and further improved into the core class `Neos\Cache\Backend\RedisBackend`.

Thus, to update, you need to go to your `Caches.yaml` and replace all occurences of `Sandstorm\OptimizedRedisCacheBackend\OptimizedRedisCacheBackend` with `Neos\Cache\Backend\RedisBackend`.

---

---

---

---

Original Readme for Neos &lt; 8.0
---------------------------------

[](#original-readme-for-neos--80)

- for usage as Content Cache
- needed if the same tags apply to many elements

Installation
------------

[](#installation)

```
composer require sandstorm/optimizedrediscachebackend
```

Version compatibility:

- > = 1.1.4: Support for `Neos.Flow.cache.applicationIdentifier` in `Settings.yaml` - this is only supported with the following Flow versions, because we rely on [this core bugfix](https://github.com/neos/flow-development-collection/pull/2622/commits/98af394ae947c59f851ac260449b293ccfe448b0):

    - 6.3.14 or newer (and &lt; 7.0)
    - 7.0.11 or newer (and &lt; 7.1)
    - 7.1.5 or newer (and &lt; 7.2)
    - 7.2.2 or newer
    - 7.3.0 or newer (and all future versions)
- &lt;= 1.1.3 - Flow 6 and 7 (all versions)

Usage
-----

[](#usage)

in Caches.yaml, do:

```
Neos_Fusion_Content:
  backend: Sandstorm\OptimizedRedisCacheBackend\OptimizedRedisCacheBackend

Neos_Media_ImageSize:
  backend: Sandstorm\OptimizedRedisCacheBackend\OptimizedRedisCacheBackend

Flow_Mvc_Routing_Route:
  backend: Sandstorm\OptimizedRedisCacheBackend\OptimizedRedisCacheBackend

Flow_Mvc_Routing_Resolve:
  backend: Sandstorm\OptimizedRedisCacheBackend\OptimizedRedisCacheBackend
```

If you are using a symlink-based deployment, you should set the `flushRedisDatabaseCompletely` option as follows to remove stale data from previous releases (and ensure you use one redis DB per cache):

```
Neos_Fusion_Content:
  backend: Sandstorm\OptimizedRedisCacheBackend\OptimizedRedisCacheBackend
  backendOptions:
    flushRedisDatabaseCompletely: true
```

Problems with the current Redis cache implementation
----------------------------------------------------

[](#problems-with-the-current-redis-cache-implementation)

- When doing a flushByTag, we do the following (pseudocode):

    - *iterate* over all entries for this tag
        - "unlink" the entry from all tags this entry is additionally tagged with
            - *iterate* over all tags for the current entry
        - remove the entry
        - remove the entry-&gt;tags relation
    - remove the tag
- You see, we have a twicely-nested iteration going on here. In a big customer project, the inner loop is sometimes called over 100 000 times for a single tag flush; making the Redis server unresponsive while the script runs.

Optimizations in this cache backend
-----------------------------------

[](#optimizations-in-this-cache-backend)

### Optimized FlushByTag

[](#optimized-flushbytag)

When doing flushByTag, we just do the following:

```
- *iterate* over all entries for this tag
  - remove the entry
  - remove the entry->tags relation
- remove the tag

```

**this means that the *other* tags for the cache entries are not removed**.

- This leaves some "cruft" in the Redis cache; namely tags where their assigned entries are already gone. This is not a big problem, as the entries might have also just timed out (because they have a TTL).
- The only scenario I see where this might become a problem is:

    - entry1 with tags A,B is inserted
    - flushByTag(A) is done -&gt; entry1 is removed, tag A is removed, tag B still exists, pointing to the (non-existing) entry1
    - entry1 with tag A is inserted **(Tag associations have changed!)**
    - -&gt; there still is a connection between tag B (which has not been removed) and entry1.
- When relying on findIdentifiersByTag() of TaggableBackendInterface, this might be a problem -- but this is never used in the content cache.
- Aside from findIdentifiersByTag(), tags are only used for *clearing* certain parts of the cache. Thus, a stale edge from Tag B -&gt; entry1 might lead to entry1 *being flushed too often*. **We assume that this does not matter much for the content cache.**
- **If the user wants to remove the cruft completely, he should call flush(), which completely resets the cache.**
- The whole scenario above is not so likely, because cache tags are mostly controlled by Fusion; and as long as this does not change, the cache tags stay stable.

### Removal of entries list of standard cache backend

[](#removal-of-entries-list-of-standard-cache-backend)

The default Redis cache backend as an `entries` list storing all cache entries (needed for iteration on legacy Redis versions). Finding elements in the list is O(n) in the number of list entries.

Today, one could use KEYS for iterating over entries; but our content cache does not rely on IterableBackendInterface. Thus, we just remove the `entries` altogether.

### More simple flush() implementation

[](#more-simple-flush-implementation)

For implementing flush(), we just iterate over the relevant part of the keyspace and remove all elements. Before, this was done through a similar logic as explained in FlushByTag, because the Redis Backend was freezable (but we do not need this for Neos Content Cache).

###  Health Score

39

—

LowBetter than 86% of packages

Maintenance17

Infrequent updates — may be unmaintained

Popularity35

Limited adoption so far

Community20

Small or concentrated contributor base

Maturity70

Established project with proven stability

 Bus Factor1

Top contributor holds 70.6% of commits — single point of failure

How is this calculated?**Maintenance (25%)** — Last commit recency, latest release date, and issue-to-star ratio. Uses a 2-year decay window.

**Popularity (30%)** — Total and monthly downloads, GitHub stars, and forks. Logarithmic scaling prevents top-heavy scores.

**Community (15%)** — Contributors, dependents, forks, watchers, and maintainers. Measures real ecosystem engagement.

**Maturity (30%)** — Project age, version count, PHP version support, and release stability.

###  Release Activity

Cadence

Every ~161 days

Recently: every ~168 days

Total

11

Last Release

1545d ago

Major Versions

0.1.0 → 1.0.02019-08-21

### Community

Maintainers

![](https://www.gravatar.com/avatar/2ced0d63cfdae881c32128c7f66451a013d3e24d9eed210d6a846b6d8e95fa3b?d=identicon)[sandstorm](/maintainers/sandstorm)

---

Top Contributors

[![skurfuerst](https://avatars.githubusercontent.com/u/190777?v=4)](https://github.com/skurfuerst "skurfuerst (24 commits)")[![bwaidelich](https://avatars.githubusercontent.com/u/307571?v=4)](https://github.com/bwaidelich "bwaidelich (3 commits)")[![dimaip](https://avatars.githubusercontent.com/u/837032?v=4)](https://github.com/dimaip "dimaip (3 commits)")[![saschanowak](https://avatars.githubusercontent.com/u/1643495?v=4)](https://github.com/saschanowak "saschanowak (2 commits)")[![daniellienert](https://avatars.githubusercontent.com/u/642226?v=4)](https://github.com/daniellienert "daniellienert (1 commits)")[![rolandschuetz](https://avatars.githubusercontent.com/u/735982?v=4)](https://github.com/rolandschuetz "rolandschuetz (1 commits)")

### Embed Badge

![Health badge](/badges/sandstorm-optimizedrediscachebackend/health.svg)

```
[![Health](https://phpackages.com/badges/sandstorm-optimizedrediscachebackend/health.svg)](https://phpackages.com/packages/sandstorm-optimizedrediscachebackend)
```

###  Alternatives

[react/cache

Async, Promise-based cache interface for ReactPHP

444112.4M40](/packages/react-cache)[wp-media/wp-rocket

Performance optimization plugin for WordPress

7431.3M3](/packages/wp-media-wp-rocket)[illuminate/cache

The Illuminate Cache package.

12835.6M1.4k](/packages/illuminate-cache)[colinmollenhour/php-redis-session-abstract

A Redis-based session handler with optimistic locking

6325.6M14](/packages/colinmollenhour-php-redis-session-abstract)[cheprasov/php-redis-client

Php client for Redis. It is a fast, fully-functional and user-friendly client for Redis, optimized for performance. RedisClient supports the latest versions of Redis starting from 2.6 to 6.0

1281.2M21](/packages/cheprasov-php-redis-client)[amphp/redis

Efficient asynchronous communication with Redis servers, enabling scalable and responsive data storage and retrieval.

165634.7k44](/packages/amphp-redis)

PHPackages © 2026

[Directory](/)[Categories](/categories)[Trending](/trending)[Changelog](/changelog)[Analyze](/analyze)
