Modify cache redis backend

[pantaovay]

Changes

1. Modify cache redis backend, delete _PHCR
2. Cache redis backend supports "client" option, now you can pass a redis client
3. Redis's set method supports ttl,the call of settimeout is removed
4. Redis has existsmethod to check if a key exists, the previous implementation uses get which is wrong

Why

1. The redis cache backend use a special key _PHCR to store all keys used by cache. There is a issue: #10905 .According to @Green-Cat ,it is disabled in 2.0.x branch which is not true. If use _PHCR, every time we set a cache, we have to run sAdd and set commands. Store all keys in _PHCR will cause it expands quickly and this will influence performance.
2. The previous implementation mixes statsKey and prefix, it uses _PHCR as super prefix which is not needed.
3. The cache backend doesn't support redis option which means that we can not pass a redis connection. So if we use modelsCache and modelsMetadata, there will be two redis connections. So I modify this part and let redis option be supported, and through the lifetime of a request we can use one redis connection.

[pantaovay]

See #11452

[pantaovay]

@sergeyklay 😊

[sergeyklay]

I'll look into this as soon as I can

[sergeyklay]

Modify cache redis backend, delete _PHCR

As I remember it was done in pantaovay@6b88422

Why are we again added _PHCR ?

[pantaovay]

Because it is inconsistent with the document. But current implementation is inconsistent with other cache backends😭. I will modify the document instead.

[sergeyklay]

the _ prefix is inconsistent with common style of public Phalcon methods

[sergeyklay]

It seems to me getInternalHandler would be better

[pantaovay]

Would private be better?

[sergeyklay]

could you please explain this a bit more

[pantaovay]

All the use of keyName in other methods is if !keyName, I think this is inconsistent. In libmemcached and memcache, if keyName === null is used in the save method too. Maybe all of them should be if !keyName?

[pantaovay]

If user passs empty string or 0... An empty string is not allowed but 0 should be allowed.

I think the check should be

        if keyName === null || keyName === "" {
            let lastKey = this->_lastKey;
        } else {
            let lastKey = this->_prefix . keyName;
            let this->_lastKey = lastKey;
        }

[pantaovay]

And I find that statsKey can not be set as "0"

[sergeyklay]

anyway

this->_getRedis()->sMembers(specialKey);

is expensive than

var redis;
let redis = this->_getRedis();

redis->sMembers(specialKey);

[pantaovay]

I don't know much about this. I will modify this part😊

[JCMais]

Is that PR still being worked on?

[tigran-a]

Hi, just to let you know, this _PHCR is a pain for us, it eats all the memory from our Redis: the keys are stored with TTL, so after they expire, redis removes it, but _PHCR keeps growing regardless if the keys exist or not (there is no explicit key removal from php, we rely on TTL). Why not to modify all cache backends that they'd interpret null value as not to use the stats key?

[tigran-a]

Sorry for using a language that is not related to the project, but this what we have to run from time to time to clean up that key without affecting the production, maybe it might be useful for someone else:

import redis
import socket
KEY = '_PHCR'
r = redis.Redis(host=socket.gethostname())
c = r.scard(KEY)
print("%s has %d elements"%(KEY, c)) 
print("Starting removing the key values. This can take some time") 
t = r.sscan(KEY)
if t[1]:
    r.srem(KEY, *t[1])
while t[0]:
    t = r.sscan(KEY, t[0])
    if t[1]:
        r.srem(KEY, *t[1])
c = r.scard(KEY)
print("%s has %d elements"%(KEY, c)) 

[wcoppens]

Just to let you know, the _PHCR prefix really is annoying. We for instance use the redis cache across multiple applications. Phalcon in our case created the redis cache data since it acts as a receiver of measurement data. In Phalcon 1.x with the incubator package we did not have the prefix behavior and so all the cached data in Redis is not prefixed. However since we can't stay legacy we are forced to upgrade resulting in upgrading our whole application stack to support the prefix... It would really help us if there would come a solution in which the key is optional.

[aat2703]

Will this be added to 3.3.3? Really Looking forward to it 😁

[niden]

Closing in favor of #13563