Discussion :

[Willpower]

Bonjour,

Je débute encore en php, j'aimerai savoir ce que vous me conseillez pour afficher sur mon site des données provenants de la base de données tels que les stats (nombre de visiteurs etc...).

Ca fait à chaque affichage de page une requête sur ma table alors que cette variable pourrait être stockée qqes part.

1) stocker cette donnée dans une mini table avec d'autres stats pour économiser pleins de requêtes.

2) carrément faire des read/write file en php sur un fichier (genre txt) pour sauver le contenu de temps en temps et le lire le reste du temps. est-ce conseillé ou déconseillé ? plus lent que des appels en base de données ?

merci d'avance pour vos conseilles à un débutant.

[dev14]

2) carrément faire des read/write file en php sur un fichier (genre txt) pour sauver le contenu de temps en temps et le lire le reste du temps. est-ce conseillé ou déconseillé ? plus lent que des appels en base de données ?

C'est ce que je conseille pour ma part. Mais il faut penser à un système quotidien/hebdomadaire/.. selon le trafic qui permettrait de sauvegarder/récupérer le fichier et le remettre à 0 afin qu'il ne soit pas trop lourd au bout d'un moment.

[gene69]

ça se teste. au final une base de donnée sera un fichier écrit sur un disque, non?

sauf qu'il y a des services en plus avec su sgbd.

Si la base de données était considérablement plus performante en écriture, on utiliserait ça pour faire des log. mais voilà il y a la lecture qui est importante et retrouver la donnée. Retrouver une données parmi beaucoup. et la concurrence parce qu'en php tous le code peut être exécute simultanément ou jamais.

Ta question n'a même pas bcp de sens. parce que tu vas dépendre des mécanisme de cache d’écriture & de lecture, de la saturation de ton espace de stockage et de la distance de celui-ci.

[grunk]

Ecrire le résultat de requête dans un cache n'a d'intérêt que dans certains cas :

- La requête est complexe et longue à executer , dans ce cas on est certains qu'une simple lecture de fichier sera plus rapide, qu'un recalcul.

- La base est sur un autre serveur , on s'affranchie donc des latences du réseau , en passant par un fichier de cache.

- La base est limité en nombre de connexion et tu atteint souvent le maximum sans possibilité d'évoluer. Un fichier de cache délestera la base.

Après faut pas non plus avoir la phobie de la requête , un SGBD est conçu pour stocker de nombreuses données et les récupérer

Il faut aussi faire attention au cache qui parfois peux dérouter l'utilisateur qui peut ne pas voir une information tout de suite

[CinePhil]

Tout dépend de la fraîcheur attendue du résultat de ces statistiques.

S'il s'agit d'afficher, par exemple, un classement tel qu'il était à 1h du matin, tu peux avoir un programme qui fait les calculs à 1h du matin et qui enregistre le résultat dans un fichier texte. Inutile de recalculer le classement 382402 fois si le tableau du classement s'affiche autant de fois dans la journée.

Si par contre ces stats doivent être mises à jour en quasi-temps réel après l'action des utilisateurs, alors il vaut mieux recalculer à chaque fois.

[rawsrc]

Bonjour,

Si par contre ces stats doivent être mises à jour en quasi-temps réel après l'action des utilisateurs, alors il vaut mieux recalculer à chaque fois.

Et quand le recalcul est long et compliqué, stocker le résultat dans une table séparée. Dans ce cas, il faut veiller à ce que tous les accès en écriture pour les éléments concernés soient verrouillés avec des procédures stockées. Ces dernières garderont tes stats à jour.

[Willpower]

Merci pour vos réponses, mais "arg", vous ne semblez pas avoir un avis commun sur la question, ce qui ne m'aide pas beaucoup dans mais décisions.

Je fais essayer de formuler autrement :

1) Pour une donnée qui ne change pas souvent y a-t'il une formule qui lie sa complexité de calcul aux nombres d'appels identiques tolérés (avant changements) pour caluler le moment où il devient intéressant de stocker la réponse sur le coté.

Exemple: Un "SUM" de 10.000 valeurs sur une table 100.000 entrées, avec une mise à jour voulue (donc valeur approximative le reste du temps) tous les 2000 appels à la "requête ou donnée" ?

2) Pour une simple variable mise à jour toutes les x temps(minute, heure, jour) , vous me conseillez un champ en base de données ou un fichier standard ?


Encore merci de vos réponses.

[CinePhil]

Tes critères ne sont pas forcément suffisants ou assez précis pour te donner une réponse valable.

tous les 2000 appels à la "requête ou donnée" ?

Si ces 2000 appels surviennent chaque minute parce ton site est très fréquenté, inutile de faire un fichier externe qui sera obsolète toutes les minutes.

Ce que nous essayions de dire est que, grosso modo, si une requête est lourde et appelée très souvent, il peut être plus intéressant de stocker le résultat de la requête dans une table mise à jour régulièrement (mais pas trop souvent bien sûr sinon ça ne vaut pas le coup).

Ce qu'il faut savoir aussi, c'est que si la requête est exactement la même et que les données n'ont pas changé depuis sa dernière exécution, et que le résultat est encore en mémoire, le SGBD ne va pas rejouer la requête mais sortir directement le résultat de sa mémoire, ce qui est ultra rapide côté SGBD.

Selon le SGBD utilisé, tu peux aussi regarder du côté des vues matérialisées. Si c'est MySQL, n'essaie même pas de chercher, ce mauvais SGBD ne les connaît pas !

Dans tous les cas, je pense qu'il faut prototyper les solutions et les tester. Mais un bon SGBD avec une BDD bien modélisée et bien indexée doit être capable de donner le résultat d'une requête en une fraction de seconde, même avec des millions de lignes.

[rawsrc]

Ce que nous essayions de dire est que, grosso modo, si une requête est lourde et appelée très souvent, il peut être plus intéressant de stocker le résultat de la requête dans une table mise à jour régulièrement (mais pas trop souvent bien sûr sinon ça ne vaut pas le coup).

Je complèterais en ajoutant que dans certains cas, il est possible de ne pas recalculer tout depuis le début à chaque mise à jour mais partir du résultat déjà sauvegardé et ne tenir compte que du delta. Généralement ça facilite et accélère énormément le suivi de la valeur calculée.

[Willpower]

Si ces 2000 appels surviennent chaque minute parce ton site est très fréquenté, inutile de faire un fichier externe qui sera obsolète toutes les minutes.

Je prend note de tes autres remarques et te remercie pour les informations que tu m'apportes, mais néanmoins, je n'arrive pas à être d'accord (ou à comprendre ton raisonnement) sur ce point.

Pour moi, ce qui est déterminant c'est d'avantage le nombre de requêtes fournissant un résultat similaire que le "temps" durant lequel le résultat sera similaire.

Si mon résultat ne change pas pendant 24h mais qu'il n'y a que 10 appels durant ces 24h, ça ne semble pas valoir la peine de stocker le résultat qqe part.

Si au contraire, le résultat change toutes les 30 minutes mais qu'il y a 100.000 appels similaires (donnant le même résultat) durant ces 30 minutes, je préférerai stocker le résultat quelque part.

---

@rawsrc: je note ton idée du delta, bien que celle-ci entraine 2 requêtes/lecture (le dernier résultat obtenu + le nouveau delta), dans le cas où la précision n'importe peu, je me passerai du delta. (mais je garde ton idée pour mes valeurs qui doivent être précises).

[CinePhil]

Je me contenterai de répondre en répétant la fin de mon précédent message :

Selon le SGBD utilisé, tu peux aussi regarder du côté des vues matérialisées. Si c'est MySQL, n'essaie même pas de chercher, ce mauvais SGBD ne les connaît pas !

Dans tous les cas, je pense qu'il faut prototyper les solutions et les tester. Mais un bon SGBD avec une BDD bien modélisée et bien indexée doit être capable de donner le résultat d'une requête en une fraction de seconde, même avec des millions de lignes.