Dans le monde de l’infrastructure, les tendances changent, mais les besoins restent souvent les mêmes : moins de latence, moins de CPU par requête et moins de surprises en production. Sur ce terrain — où Redis, Memcached, Valkey ou Dragonfly sont depuis des années des noms familiers — un nouveau venu commence à faire du bruit : Pogocache. Écrit en C, ce serveur de cache se targue d’être entièrement optimisé « dès la conception » pour offrir des réponses rapides et une efficacité CPU accrue. Il joue également une carte inhabituelle : supporte plusieurs protocoles d’un seul coup.
Le principe est simple : une seule pièce de logiciel pouvant agir comme cache consommable avec des outils et bibliothèques existants, car il comprend Memcache, RESP (Valkey/Redis), HTTP, et même le protocole de communication de Postgres. Pour des équipes souhaitant changer de moteur sans réécrire la moitié de leur stack, cette compatibilité est presque la caractéristique principale : il peut être testé avec redis-cli/valkey-cli, avec curl, psql ou les clients Memcached traditionnels.
Qu’est-ce exactement que Pogocache (et pourquoi ce n’est pas « un autre Redis »)
Pogocache se présente comme un cache clé-valeur destiné à fonctionner en tant que service (démon), mais propose aussi une option peu courante : mode embarqué. Au lieu d’exposer un port et de communiquer via réseau, il peut être compilé directement dans votre logiciel grâce à un fichier autonome (pogocache.c), évitant ainsi les coûts liés au réseau lorsque l’objectif est de maximiser la vitesse d’exécution.
Au niveau du design, son approche repose sur :
- Hashmap partitionnée (plusieurs « shards » pour répartir la charge).
- Hashing Robin Hood (pour mieux gérer les collisions).
- Verrous légers par shard.
- Modèle réseau multi-threads avec boucles d’événements (epoll/kqueue) et optimisations comme
io_uringsous Linux lorsque disponible.
En résumé : il est conçu pour que les opérations courantes (SET/GET/DEL) soient peu coûteuses en CPU et stable en latence, précisément là où les performances peinent à l’échelle.
Comparatif de performance : ce que montrent des benchmarks « dans les conditions »
Il faut rester honnête : il n’existe pas de « meilleur » cache universel. Tout dépend du matériel, de la charge, de la taille des valeurs, du pipelining, de la persistance, du réseau, etc. Cependant, Pogocache a su se faire une place avec des chiffres concrets et reproductibles.
Dans ses tests publics (8 threads sur une instance AWS c8g.8xlarge), Pogocache affiche avec 3,08 millions de QPS, devant d’autres solutions populaires dans ce contexte :
- Pogocache : 3,08 M QPS
- Memcached : 2,60 M QPS
- Garnet : 1,54 M QPS
- Redis : 1,51 M QPS
- Dragonfly : 1,41 M QPS
- Valkey : 1,33 M QPS
Ce qui importe, c’est la méthode de mesure. Dans le dépôt des benchmarks, il est précisé que les tests ont été réalisés avec memtier_benchmark, en connexions locales (pipes UNIX), sans persistance, avec 31 exécutions par graphique, en utilisant la médiane comme valeur représentative, ainsi que les percentiles de latence (p50/p90/p99+), et les cycles CPU mesurés avec perf. En clair : ce n’est pas un simple graphique sans méthodologie : il y a un contexte précis et une répétition.
Cela signifie-t-il que chacun obtiendra exactement ce +X% ? Non. Mais cela donne une tendance : si votre limite est la latence ou l’utilisation CPU au niveau du cache, Pogocache mérite au moins une expérimentation contrôlée.
Comment installer Pogocache
Option 1 : compilation à partir du code source
Sur les systèmes Linux/macOS (64 bits), le processus classique consiste à :
git clone https://github.com/tidwall/pogocache
cd pogocache
make
Ce qui génère le binaire pogocache.
Option 2 : Docker
Pour essayer rapidement sans toucher à la configuration du système :
docker run --net=host pogocache/pogocache
(Dans les environnements où --net=host ne convient pas, il faudra mapper manuellement les ports.)
Démarrer Pogocache (et faire le minimum pour la production)
Par défaut, il démarre sur 127.0.0.1:9401 :
./pogocache
Pour qu’il écoute sur une autre IP :
./pogocache -h 0.0.0.0
Et quelques options utiles :
--threads: nombre d’threads d’IO.--maxmemory: limite mémoire (par défaut, un pourcentage).--evict: activer l’éviction lors de l’atteinte de la limite mémoire.--auth: définir un mot de passe/token pour l’authentification.- TLS :
--tlsport,--tlscert,--tlskey,--tlscacert.
Exemple avec mot de passe :
./pogocache --auth "MonMotDePasseTrèsLong"
Comment l’utiliser : 3 méthodes concrètes (HTTP, Redis/Valkey et Postgres)
1) HTTP avec curl (PUT / GET / DELETE)
Pour stocker :
curl -X PUT -d "ma valeur" http://localhost:9401/ma-cle
Pour lire :
curl http://localhost:9401/ma-cle
Pour supprimer :
curl -X DELETE http://localhost:9401/ma-cle
Ou avec TTL en paramètre de requête (en secondes) :
curl -X PUT -d "valeur avec TTL" "http://localhost:9401/ma-cle?ttl=15"
2) RESP (Valkey/Redis) avec valkey-cli ou redis-cli
valkey-cli -p 9401
SET ma-cle ma-valeur
GET ma-cle
DEL ma-cle
Si vous avez activé --auth :
valkey-cli -p 9401 -a "MonMotDePasseTrèsLong"
3) Mode Postgres avec psql (oui, comme c’est indiqué)
Se connecter :
psql -h localhost -p 9401
Et utiliser :
SET ma-cle = 'ma valeur';
GET ma-cle;
DEL ma-cle;
Cette approche ouvre une possibilité intéressante : utiliser les librairies Postgres dans des langages où le tooling est déjà mature, ou même automatiser des tests avec psql sans installer de clients Redis spécifiques.
Dans quels cas cela a du sens (et quand éviter)
Pogocache est idéal lorsque :
- Vous recherchez une vitesse maximale pour des opérations simples (GET/SET/DEL).
- Vous souhaitez remplacer ou compléter Redis/Memcached sans changer de client.
- La possibilité d’embeder la couche cache dans votre logiciel vous paraît pertinente pour réduire la latence.
- La priorité est latence ultra-faible + efficacité CPU, sans nécessité de fonctionnalités avancées.
À l’inverse, il vaut mieux réfléchir si :
- Vous avez besoin d’un écosystème riche en modules, scripts et intégrations prédéfinies pour Redis.
- Une haute disponibilité distribuée « prête à l’emploi » est une exigence incontournable (Actuellement, Pogocache privilégie l’efficacité à l’échelle du nœud plutôt que la distribution out-of-the-box, mais son équipe planche sur le sujet).
Foire aux questions
Pogocache peut-il remplacer Redis dans un projet existant ?
Dans beaucoup de cas, oui, notamment au niveau protocole (RESP) et commandes courantes (SET, GET, DEL, TTL, EXPIRE). La clé est de vérifier si votre application utilise des fonctionnalités avancées spécifiques à Redis.
Quel avantage y a-t-il à supporter HTTP et Postgres en plus de Redis/Memcached ?
Cela facilite la compatibilité : on peut tester et utiliser avec des outils universels (curl) ou s’intégrer dans des environnements déjà équipés en Postgres (psql, drivers), sans dépendre de clients spécialisés.
Les benchmarks en QPS sont-ils « fiables » ou marketing ?
Ils sont publiés avec une méthodologie et des scripts précis, offrant une certaine traçabilité. Cependant, leur validité dépend toujours de votre charge spécifique (taille des valeurs, concurrence, réseau, persistance, etc.).
Comment Pogocache garantit-il la fiabilité en production ?
Il inclut une authentification par mot de passe/token, une prise en charge TLS/HTTPS via des flags lors du lancement, et permet de limiter les ressources (nombres de threads, mémoire, connexions) tout en contrôlant la politique d’expulsion.
Source : Administración de Sistemas
