lustmored/flysystem-v2-simple-cache-adapter

Simple flysystem PSR cache adapter decorator.

0.3.0 2022-01-17 09:53 UTC

Requires

• php: >=7.2
• league/flysystem: ^2.0 | ^3.0
• psr/cache: ^1.0 | ^2.0 | ^3.0

Requires (Dev)

• ext-redis: *
• friendsofphp/php-cs-fixer: ^3.0
• league/flysystem-adapter-test-utilities: ^2.0 | ^3.0
• league/flysystem-aws-s3-v3: ^2.0 | ^3.0
• league/flysystem-memory: ^2.0 | ^3.0
• phpbench/phpbench: ^1.0.2
• phpunit/phpunit: ^9.4
• symfony/cache: ^5.4 | ^6.0
• symfony/dotenv: ^5.4 | ^6.0

MIT

• Jakub Caban

README

Simple cache decorator for Flysystem v2 Adapters.

Installation

composer require lustmored/flysystem-v2-simple-cache-adapter

Usage

CacheAdapter takes simply 2 parameters:

• $adapter - Filesystem adapter to be decorated
• $cachePool - PSR-6 compliant cache pool object

Example configuration in Symfony with flysystem-bundle (thanks to @weaverryan for summarizing things up):

[OPTIONAL] Create Cache pool to use:

# config/packages/cache.yaml
framework:
    cache:
        pools:
            cache.flysystem.psr6:
                adapter: cache.app

Configure service. Here @flysystem.adapter.uploads_adapter is Flysystem adapter (based on flysystem-bundle configuration for uploads_adapter storage):

# config/services.yaml
services:
    # ...

    flysystem.cache.adapter:
        class: Lustmored\Flysystem\Cache\CacheAdapter
        arguments:
            $adapter: '@flysystem.adapter.uploads_adapter'
            $cachePool: '@cache.flysystem.psr6'

Finally, wire it up into flysytem-bundle:

# config/packages/flysystem.yaml
flysystem:
    storages:
        # ... your other storages

        cached_public_uploads_storage:
            # point this at your service id from above
            adapter: 'flysystem.cache.adapter'

Architecture

Please note this library is in early stages and cache format or functionality may change. I've created it for my own project and needs.

Idea is from flysystem-cached-driver, but cache logic is rethought. Instead of one big cache (that is killing memory when you have tens of thousands of files) it stores items on per-file basis.

Therefore, at least for now, there is no gain on listContents method, yet potential huge gains for fileExists and metadata-related methods (especially on network/cloud filesystems, like S3).

Performance

Benchmarks run with Redis in Docker (via provided docker-compose.yml). S3 benchmarks require setting environment vars (for example by providing .env.bench.local). Cached benchmarks have cache warmed by calling listContents.

Below are reports from single benchmark run on devel machine as of 0.0.4. They show that caching metadata with the local adapter makes no sense, while using it for S3 brings potential huge benefits when querying existing files. fileExists benchmark randomly queries files with about 50% of them existing.