En scrutant le code source, je me suis aperçu de ceci :
Fichier class/cache.class.php
case 'RedisCache':
$redis = new Redis();
$redisAddr = config::byKey('cache::redisaddr');
if (strncmp($redisAddr, '/', 1) === 0) {
$redis->connect($redisAddr);
} else {
$redis->connect($redisAddr, config::byKey('cache::redisport'));
}
self::$cache = new \Doctrine\Common\Cache\RedisCache();
self::$cache->setRedis($redis);
break;
default:
self::$cache = new \Doctrine\Common\Cache\FilesystemCache(self::getFolder());
break;
La prise en charge de Redis semble être implémentée. Serait-il possible d’ajouter simplement la possibilité de le configurer dans la page de configuration de cache afin que cela soit plus « simple » ?
Je suis d’accord avec toi mais cela n’a pas l’air d’intéresser grand monde /D
Et par la même occasion et plutôt plus généralement, avoir une doc sur l’optimisation de jeedom via un autre cache que filesystem.
Peut être qu’un guru pourra venir nous en dire plus?
Pour ma part, je souhaite, dans un premier temps, tenter de faire communiquer mon conteneur Jeedom avec mon conteneur Redis.
J’utilise Redis avec Nextcloud et Vault (pour la gestion des secrets).
Dès que je pourrais, je vais tenter de passer du temps sur le sujet. Après tout, si les premières briques sont là, il se peux que ce soit juste un peu de config à faire.
Dans la configuration de mon Jeedom (https://jeedom.xx/index.php?v=d&p=administration#cachetab), je ne peux que sélectionner « Système de fichiers ».
Savez-vous comment activer l’utilisation d’un autre moteur de cache ?
J’utilise Redis pour Nextcloud et j’aimerais aussi que Jeedom puisse bénéficier de cet outil externe.
Je n’ai trouvé aucun système, dans le code de Jeedom, migrant les données du cache existant vers le nouveau cache. Donc, le fait de passer vers un nouveau système de cache, vide purement et simplement le cache !
Si vous changez de cache, les valeurs en place dans le nouveau cache sont utilisée. Donc : quand on migre vers un cache vide => pas (trop) de problème, mais quand on migre vers un cache déjà alimenté par le passé => de (très) anciennes valeurs peuvent revenir pourrir les historiques, les scenarios, etc
Si vous vous plantez dans les valeurs entrées dans Jeedom ou lors de la config du cache, il n’y a pas de pre-check, pas de filet de secours, donc cache inaccessible => Jeedom qui se vautre en boucle.
La vrai question c’est quel avantage pensez-vous trouver à utiliser un autre moteur de cache?
pas sur que jeedom en usage domestique, seul dans son coin, va gagner à utiliser memcached ou redis vs filesystem mais il faudrait benchmarl et avoir les chiffres pour savoir
edit: j’ai fait le test rapidement chez moi avec memcached et sur mon install je gagne en écriture mais je perd l’équivalent en lecture.
Je n’ai pas l’analyse complète mais je parierais plutôt qu’on lit plus souvent le cache que ce qu’on écrit, si c’est le cas mieux vaut rester sur un cache filesystem.
Bonjour,
Comment peut-on vérifier que le /tmp est monté en ram ou pas ? Et comment le faire si ce n’est pas déjà fait ?
Autre question, dans le cas où mon jeedom est dans un container docker, je dois donc monter le /tmp du container dans la ram de l’host - ça parait logique - c’est possible nativement ? Ou bien il faut partager le /tmp avec un rép de l’host, lequel sera à son tour monté en ram ?
Bonjour
Regarde la documentation d’installation en mode docker je l’ai mise a jour il y a quelques semaines en ajoutant une partie avec docker compose qui permet d’avoir le tmp en ram.
mais cela n’a pas l’air d’intéresser grand monde /D
