Reprise du message précédent :

 
Sauf si tu utilises un technique de cache mémoire ( ).
 
Mes options sont stockées en DB, copiées dans un tableau hashé pour une recherche performante, le tout en mémoire partagée pour le récupérer à chaque script sans passer par la DB.
 
Niveau mise à jour des options aucun soucis, dans mon record en mémoire partagée j'ai des mechanismes de synchro et comme on doit passer par mes classes pour modifier une option ca oblige un reload automatique à chaque modif, donc aucun delai de mise à jour.
 
Notez au passage que si le mechanisme est plutôt simple à mettre en oeuvre avec un bon langage ( ), c'est aussi possible en PHP: http://fr.php.net/manual/en/function.shm-attach.php

J'ai pas tout compris tu dis passer par la DB, ensuite que c'est stocké en memoire partagée pour ne avoir à passer par la DB....
 

 
J'ai compris

 
 
DB // Mémoire Partagée // Utilisation en PHP
 
Souplesse de la DB et plus rapide qu'un fichier  

C'est une bonne idée. Je vais m'y interesser. Tu as pu faire des tests de perfs dessus? Du style, une boucle de 10000 itrations sur l'initialisation de l'environnement afin de voir la difference flagrante qui me fera changer d'avis. pour l'info en tout cas. Bientot mes pages vont s'afficher avant qu'on ne les demande

Nous sommes d'accord donc .

 
Non, c'est intégré dans un projet beaucoup plus vaste et cette feature était codée dès le début et dans un autre langage surtout    
 
Le gain de perf ne sera pas miraculeux non plus, mais ca évite au moins un query à chaque page  

C'est surtout par rapport à l'ouverture d'un fichier de conf. Je ferais un test ce soir si j'en ai le temps.

les forums cai de la merde

 
T'entends quoi par là ?
 
Sinon, y'a un truc que je suis pas sur d'avoir bien compris dans les notes, pour calculer la taille prise en mémoire :

 
Donc pour chaque variable ça prends 44 octets ou je me plante ?

[quotemsg=1110101,10083,87716]T'entends quoi par là ?
[/quote]
 
Que j'ai des tableaux qui sont prévu pour un accès ultra rapide en recherche via un clé (je suppose, enfin, j'ose supposer, comme PHP à ce propos). La par contre j'avais fait des tests, entre mon tableau hashé et un tableau de base, pour le générer ca prends le double du temps, mais pour aller y chercher une variable après je divise le temps quasi par 100, et comme il est généré 2* l'an maximum, c'est acceptable de perdre 1ms  
 
Pour l'autre question désolé, j'utilise pas cette fonction PHP, je sais pas comment ils ont goupillé cela autour de l'API, mais bon, même si y a un overhead de la moitié de ce que tu stockes, c'est les options globales, pas pour un utilisateur, donc "négligeable" ;-)

zion, je viens d'essayer les shm. Apres test sur le chargement de mon fichier de conf, il s'avere que la difference n'est pas flagrante, car de l'ordre du 1/10 000 de seconde. Je suppose que le fait d'utiliser un cache PHP doit serieusement reduire l'ecart.

 
Là jvais essayer de me servir de ça, cet aprem j'avais la flemme mais là je suis motivé
 
T'a testé dans une grosse boucle?
 
 
edit: mais quand on mets une variable en mémoire partagée, elle reste pas dedans juste la durée du script j'espère ?  (ou alors il y'a une astuce pour qu'elle y reste ? )

heureusement que non, sinon elle ne servirait à rien. J'ai fait une boucle sur 1000 iterations. Mais meme en test unitaire, c'est pas flagrant.

 
Euh, t'as comparé quoi la? La config dans un fichier par rapport à la config en mémoire partagée?
Je veux bien croire que la différence ne soit pas énorme la dessus
 
Mais 1000 itérations c'est pas beaucoup, j'ai des centaines d'options (j'ai pas que le forum pour ma part) et beaucoup, mais alors beaucoup d'accès à ces options  

t'a testé entre ouvrir un fichier et lire en mémoire partagée, 1000 fois ?

 
OK  

oui, la difference commence à se faire sentir. Sur 10000x c'est impressionnant. Mais ce n'est pas vraiment representatif. Je pense pas que PHP apprecie de charger 10000x le mm fichier.

 
Oui, mais ici l'intéressant serait entre loader de la DB vers le partagé ou de loader de la DB à chaque fois

 
En gros, on vérifie à chaque fois si les données existent en mémoire partagée, si oui on les prends, sinon on va voir dans la db et on les mets au passage dans la mémoire partagée ..?

 
Perso je ne vois pas de gros interets de le faire . On se doute bien que la difference sera flagrante. Par contre, ce systeme ne m'interesse pas dans le sens où je n'ai pas besoin de stocker ma conf en base.

 
Moi non plus, vu le peu d'optimisations et le nombre énorme de requetes que je fais pour le moindre truc, ca changera rien, c'est pour le fun et pour savoir le faire si un jour j'en ai vraiment besoin

Si possible THE REAL SMILEY tu peut mettre a jour mon lien car je suis passé à la v2 de mon forum et le nom a changer c'est http://www.shark-forum.net
 
Merci d'avance

très joli design

Je n'en ai pas encore mis une seule.

 
Euh si tu n'en as pas l'utilité c'est pas forcément la peine de t'embêter avec ça hein...

 
Tu peux la plupart du temps faire autrement, si tu veux pas utiliser d'union, et inversement tu peux toujours trouver où en mettre si tu y tiens...
Au pif, pour un forum, tu veux faire une recherche dans plusieurs catégories du forum: tu peux le faire avec une union des recherches sur chaque catégorie indépendamment...
 
...mais c'est pas forcément la meilleure façon de faire!

oki

http://dev.mysql.com/doc/mysql/en/ [...] _keys.html

tiens, je crois que je vais utiliser ca pour la page de la liste des drapeaux vu que j'ai une table par categorie
ca m'evitera de faire une requete par cat. Mais est ce que c'est plus rapide et optimisé ?

 
si t'as une table par cat', à priori c'est le mieux pour tout récupérer d'un coup!

ah ben non!
Je vois pas comment tu veux avoir un résultat propre avec des jointures externes là-dessus!
C'est clairement un cas d'utilisation d'une union => tu veux grouper des résultats de sélections sur plusieurs table différentes...

J'ai 2 requêtes en particulier pour ma page de favoris, et chacune d'elle contient autant de UNION (-1) qu'il y a de catégories (forcément )
 
Ben j'étais surpris que ça restait presque aussi rapide que la même requête sur une seule de ces catégories. Bon, en même temps, j'avais pas encore beaucoup de records

 
t'as aussi une table par cat'?
Ca me parait un défaut de conception assez flagrant, pourtant...

non, j'ai plusieurs tables par cat

Mais !
Le jour où tu rajoutes une cat' il se passe quoi?

ben je rajoute un ensemble de tables tiens

...Mais c'est affreusement laid!

En vrai, vous faites tous comme ça?
Parce-que si oui, j'en veux pas, de vos forums...
 
[edit]
 
Ou alors, faut m'expliquer l'intérêt...parce-que là je comprends pas du tout...

Avec les 4150 forums que j'héberge, contenant environs 13 000 tables...
 
Impossible à faire

 
Soit 3 tables seulement par forum, en gros?
 
 
 
ben voilà à quoi je veux en venir, quoi...

Autant pour moi, 16679 catégories