Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
[LIB] librairie de cache en C ?
Bonjour,
Après quelques recherches je n'ai pas réussi à trouver de librairie C pour gérer un cache de mémoire.
J'ai vu libmemcache mais cette dernière nécessite l'installation du daemon memcache pour pouvoir fonctionner.
Existe-t-il une librairie de gestion de cache mémoire en C qui ne nécessite pas l'installation d'un programme tiers ?
J'en aurais besoin pour stocker le resultat de requêtes SQL afin de limiter les accès à la base de données.
Merci d'avance
Pourquoi ne pas le faire toi-même avec un simple système LRU? Cela ne devrait pas prendre trop de temps et tu aurais la plus grande prise sur ce qu'il s'y passe.
Jc
Les resultats de mes requêtes SQL sont stockés dans des structures, ce sont donc ces structures que je souhaite monter en cache. Il y a plusieurs types de structures différentes bien sûr.
Comment ça s'implémente une pile LRU, avec une liste chainée ?
Pour identifier les éléments de mon cache je dois utiliser une sorte de checksum je suppose ?
Etant donné la charge imposée à mon programme, plusieurs occurences du même binaire sont executés et tournent en parrallèle. Pour que chaque occurence puisse partager le même cache, il faut utiliser de la mémoire partagé non ?
Je sens que ça va pas être simple à faire ce truc
Si tu as plusieurs processus qui tournent en parallèle (soit plusieurs executables, ou soit des fork), alors oui, à priori il faudra de la mémoire partagée.tant donné la charge imposée à mon programme, plusieurs occurences du même binaire sont executés et tournent en parrallèle. Pour que chaque occurence puisse partager le même cache, il faut utiliser de la mémoire partagé non ?
Mais si c'est toi qui a concu le programme, est-ce que tu ne peux pas passer à une gestion threadée ? Ca sera plus simple au niveau de la mise en oeuvre je pense, puisque les threads d'un même processus partagent le même espace mémoire.
Le système de thread me paraît plutôt difficile à mettre en place au niveau humain, je ne suis pas le seul à gérer cette application, et surtout pas celui qui décide des modifications majeures ! Je peux proposer bien sûr mais je connais déjà la réponse, c'est un peu la politique maison, tant que ça marche, pourquoi changer !
Merci quand même.
Bon alors ya pas de librairie de cache en C ??!!!
Quand on voit la profusion de librairies en Java, en C on a vraiment que les yeux pour pleurer...
C'est dingue alors que le C est quand même beaucoup plus vieux que la Java.
Il n'y a rien de standard.Envoyé par tomasha
Bon alors ya pas de librairie de cache en C ??!!!
Je ne vois pas bien ce que tu appelles "librairie (bibliothèque) de cache".
Ca me semble soit très 'applicatif' (genre, je tape le début d'une commande, et la suite vient toute seule par défaut), soit éventuellement 'système' (auquel cas, ce serait plus une fonction du serveur que du client, AMA...).
C'est pour économiser quoi exactement ?
Apparemment, une sorte de table de hachage:
requete SQL --> structure contenant les résultats
A mon avis une table de hachage semble plus adaptée, puisque à chaque requète correspond 1 et 1 seul resultat. Le checksum est justement géré par la fonction de hachage. C'est avec cette fonction (CRC, MD5, ...) qu'elle va pouvoir retrouver en temps constant l'élément que tu cherches.Comment ça s'implémente une pile LRU, avec une liste chainée ?
Pour identifier les éléments de mon cache je dois utiliser une sorte de checksum je suppose ?
Après à toi d'implémenter un système de "table de hachage LRU" si tu ne veux pas qu'elle dépasse une certaine taille (100 requètes max par exemple). Tu pourrais stocker dans une liste à part (qui elle n'est pas limitée) la fréquence de toutes les requètes et leur état (en cache ou non). Tu pourras ainsi mettre à jour ta table pour qu'elle ne contienne que les requetes le plus fréquentes. Ca peut être fait soit à chaque nouvelle requète (bof), ou alors dans un thread qui effectue la mise à jour dès que le système n'est pas trop surchargé.
Mais on rentre plus dans des considérations algorithmiques. Donc à voir avec le forum correspondantSauf si tu as des questions sur l'implémentation d'une table de hachage en C bien sûr !
J'appelle "librairie de cache" une librairie permettant le stockage de différentes données structurées, afin d'y accéder rapidement.
Je consulte régulièrement une base de donnée pour récupérer des données, lorsque ces données sont peu volatiles (elles ne changent pas souvent), je souhaiterais les stocker dans un "cache" après la consultation de la base.
Ainsi lorsque je souhaite accéder à ces données, je questionne d'abord le cache, si elles sont là tant mieux, j'économise un accès à la base, sinon je consulte la base et je stocke le résultat dans le cache. Et ainsi de suite.
Je me suis déjà créé une petite librairie qui implémente une table de hashage, mais ça ne stocke que des chaines de caractères, pas des structures...
En fait je stocke mes resultset de requêtes SQL dans des structures dont chaque champs correspond à une colonne du resultset. Suivant les resultset, c'est donc pas les mêmes structures.
Une table de hashage qui stocke du void* c'est faisable ?
Tu peux y stocker ce que tu veux ..... mais le problème est comment retrouver le type de ce que tu as stocké si tu stockes des void* ?
Et je ne suis pas sur de comprendre pourquoi tu devrais y stocker plusieurs types différents ... tu n'as pas de structure RecordSet ? Ou alors tu as peut-être plusieurs RecordSet différents, selon les champs retournés ? (dans ce cas, presque une infinité ....
Il y a peut être une partie du design à réétudier pour permettre de manipuler ces différents types de recordset facilement.
Oui c'est le principal souci du void* !
RecordSet kesaco ?Et je ne suis pas sur de comprendre pourquoi tu devrais y stocker plusieurs types différents ... tu n'as pas de structure RecordSet ? Ou alors tu as peut-être plusieurs RecordSet différents, selon les champs retournés ? (dans ce cas, presque une infinité ....
Il y a peut être une partie du design à réétudier pour permettre de manipuler ces différents types de recordset facilement.
ResultSet pardon
Ah ok
Donc pour répondre à ta question oui j'ai plusieurs structures différentes qui correspondent chacune à un resultset particulier.
Et comment fais tu pour les différencier pour le moment ? Je pense que le problème sera le même dans la table de hachage si tu stockes des void*, donc ta solution devrait s'appliquer tout aussi bien
(et comment fais-tu pour gérer le nombre plus impressionant de resultsets différents qui peuvent être retournés par les requètes SQL ?)
Je connais l'ordre des resultsets, je sais donc où stocker chaque resultset.
Je ne suis pas spur de comprendre (encore
J'imagine que le résultat d'une rèquete peut aussi bien être des tableaux de {int,char*,float} que des tableaux de {char*,char*} par exemple. Je ne vois pas comment tu fais pour stocker ces différents résultats.
Tout-à-fait oui, chaque colonne d'un resultset peut avoir un type particulier.
Là où je me suis mal exprimé c'est que ma structure me sert pour stocker UNE ligne du resultset, et donc pour stocker le resultset entier (toutes les lignes) j'utilise un tableau de structure.
Et donc ta structure contient un tableau de void* (un pour chaque colone) ?
Ou est-ce que tu as isolé différents resultsets possibles et créés autant de structures correspondantes ?
2ème solution, j'ai autant de structures que de resultset différents, et autant de champs dans une structure que de colonnes dans le resultset correspondant.
Ca facilite beaucoup l'accès à ces données plutôt qu'un tableau de void*.
Et puis comment tu parcours un tableau de void* ? je doute que l'accès au 6ème champ (par exemple) se fasse par "champ[5]"...
Répondre avec citation
Partager