phpfastcache: getStats() (DriverStatistic) is very slow (and size is not correct) on files adapter

Configuration (optional)

PhpFastCache version: 8.0.2
PhpFastCache API version: 3.0.0
PHP version: PHP 7.4.11
Operating system: GNU/Linux (Ubuntu 18.04.5 LTS)

My question

I have two concerns here.

This is the actual output of getStats() method:

Phpfastcache\Entities\DriverStatistic Object
(
    [info:protected] => Number of files used to build the cache: 25336
    [size:protected] => 4955612
    [data:protected] => 
    [rawData:protected] => Array
        (
            [tmp] => Array
                (
                    [95febb24d3424412e9afa40e20547d1a] => /var/xyz/cache/domain.com/Files
                )

        )

)

Size - this should represent size in bytes? While in reality /var/xyz/cache/domain.com/Files has a total size of 183 MB
Performance - it takes 12 secs to load this page with stats. I’m aware files are slow (disk is not SSD), so it might be logical for 183MB of small files it takes that much to calculate, but size reported by OS / file system and getStats method are not even close?

Am I doing something wrong here?

About this issue

Original URL
State: closed
Created 4 years ago
Comments: 16 (9 by maintainers)

Most upvoted comments

More seriously you can override the Files driver to extends the getStats() methods and replace them by a shell_exec implementation 😃

Geolim4 on Oct 30, 2020

Maybe you should cache your cache stats. Ohh wait 😛

Geolim4 on Oct 30, 2020

This was v1 of the cache solution 😃 So it works superb for normal use - e.g. app asks cache store whenever the item is not expired and returns it with simple get() method call. Where it hits performance is only on getStats() method call. And that’s not used by anyone but me with special access param 😃

Indeed memcached would be next thing - but this just works for now.

I’ll try to test though with one big associative array to see if that is of any help and to measure the performance. Will be interesting.

stamster on Oct 30, 2020

However your use case tells me that you may have to think about switching to more efficient cache backend, redis maybe ?

Geolim4 on Oct 29, 2020

This is the problem with high programming level, no matter the implementation you cannot really deal easily when manipulating lot of files 😦

Geolim4 on Oct 29, 2020

The time spend is definitely caused by number of files, but I can’t really do something about it, except maybe adding a bash command which could be blocked in some installation due to the call to shell_exec 😦

Geolim4 on Oct 28, 2020

Hello,

I’m investigating, but I don’t get that size difference, would you mind to send me a ZIP of this directory /var/xyz/cache/domain.com/Files on my email if this is not too sensitive ?

contact(-at-)geolim4.com

I might have an idea, but I’m not really sure. Cheers, Georges

Geolim4 on Oct 27, 2020