J'ai pris Redis car c'est LA référence1 du domaine et qu'il est massivement utilisé. Ils ont considéré que le gain en performance ne valait pas les autres avantages. Il existe des alternatives à redis, qui font des choix différents. Mais force est de constater qu'il reste une place pour redis, malgré l'API ASCII et pendant longtemps l'absence de cluster.
Personne n'est donc plus "au courant" que par exemple le nombre 2 milliards, transféré en ascii va prendre 10 octets, et en binaire seulement 4 octets?
Et que dire du temps CPU pour convertir l'ascii ?
Ce que disent les mainteneur de redis, c'est que ce n'est pas la seule chose qu'il faut regarder et qu'ils sont prêt à payer ce coût face à d'autres avantages. On parle d'un projet qui fonctionne et qui fonctionne très bien depuis longtemps. Il a des challengers qui ont des protocoles binaires, mais ça n'a semble t'il pas suffit à le détrôner. Je veux bien te proposer d'aller en discuter avec eux, mais si tu viens avec tes gros sabots comme ici je doute que tu sois bien accueilli...
Je ne vois pas l’intérêt de Redis pour un seul serveur, une librairie faisant le même boulot, ne suffirait-elle pas?
Intéresse toi au modèle d'exécution de PHP ou des (fast)CGI par exemple. Quand tu fais spawn un process par requête (ou que tu fais un pool de thread) ça va coincer. Si tu n'a pas ou si tu ne veux pas manipuler des threads toi-même comme avec node ça peut être intéressant.
A moins que l'on considère que l'appel d'une fonction est "comparable" à l'appel d'un service réseau.
Ce n'est pas l'appel d'une fonction, c'est un IPC que tu dois utiliser donc tu a ton coût de sérialisation quoi qu'il arrive (sauf éventuellement si tu utilise des threads et pas de process, mais tu as toute la protection à fin d'être thread-safe à gérer. Plus un autre pour nettoyer tes données. Les caches sous forme de bibliothèques ça existe, mais c'est des contextes différents.
Bref, ce que fais Redis en réseau peut très bien être fait par une l'utilisation d'une librairie pour les besoins que tu précises (optimisation pour les gros volumes, fragmentation, ...) sans requérir un service.
Ça dépend du contexte. Mon (削除) po (削除ここまで) objectif c'est de te montrer qu'il y a pleins de contexte différents qui amènent à des solutions différentes et donc des solutions différentes. L'exemple de redis n'est là que parce que c'est un exemple réel qui coche toutes tes cases tout en ayant sa place et ses utilisateurs.
par là il faut comprendre que ce n'est pas le meilleur dans tous les use case, mais que tous doivent se comparer à ce dernier et c'est largement le plus utilisé. ↩
[^] # Re: Formatage automatique
Posté par barmic 🦦 . En réponse à la dépêche Robert, un logiciel de stockage en mémoire vive. Évalué à 1.
J'ai pris Redis car c'est LA référence1 du domaine et qu'il est massivement utilisé. Ils ont considéré que le gain en performance ne valait pas les autres avantages. Il existe des alternatives à redis, qui font des choix différents. Mais force est de constater qu'il reste une place pour redis, malgré l'API ASCII et pendant longtemps l'absence de cluster.
Ce que disent les mainteneur de redis, c'est que ce n'est pas la seule chose qu'il faut regarder et qu'ils sont prêt à payer ce coût face à d'autres avantages. On parle d'un projet qui fonctionne et qui fonctionne très bien depuis longtemps. Il a des challengers qui ont des protocoles binaires, mais ça n'a semble t'il pas suffit à le détrôner. Je veux bien te proposer d'aller en discuter avec eux, mais si tu viens avec tes gros sabots comme ici je doute que tu sois bien accueilli...
Intéresse toi au modèle d'exécution de PHP ou des (fast)CGI par exemple. Quand tu fais spawn un process par requête (ou que tu fais un pool de thread) ça va coincer. Si tu n'a pas ou si tu ne veux pas manipuler des threads toi-même comme avec node ça peut être intéressant.
Ce n'est pas l'appel d'une fonction, c'est un IPC que tu dois utiliser donc tu a ton coût de sérialisation quoi qu'il arrive (sauf éventuellement si tu utilise des threads et pas de process, mais tu as toute la protection à fin d'être thread-safe à gérer. Plus un autre pour nettoyer tes données. Les caches sous forme de bibliothèques ça existe, mais c'est des contextes différents.
Ça dépend du contexte. Mon
(削除) po (削除ここまで)objectif c'est de te montrer qu'il y a pleins de contexte différents qui amènent à des solutions différentes et donc des solutions différentes. L'exemple de redis n'est là que parce que c'est un exemple réel qui coche toutes tes cases tout en ayant sa place et ses utilisateurs.par là il faut comprendre que ce n'est pas le meilleur dans tous les use case, mais que tous doivent se comparer à ce dernier et c'est largement le plus utilisé. ↩
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll