12/08/2012, 11:38:29
C'est techniquement plus complexe en réalité.
Les graphes vont reposer à terme sur plusieurs axes
nombre de clic par user-agent ou par name de compteur ?
sur un cycle de 24H ? sur un cycle de 7 jours ? sur x jours ? semaines ? mois ? année ?
Soit 2 * 6 = 12 possibilités de compilation de donnée complètement différente.
Alors la solution rapide serait de pré-macher ces douzes versions, de le mettre en cache d'une manière ou d'une autre et ensuite de vider à la demande la bdd mais comment gérer le fait potentiel que dans 3 semaines après la purge on me demande un nouveau type de graphe ? c'est con de perdre nos sources non ?
edit : je viens de penser à pire : on peut regrouper ses compteurs par tag, et faire des graphes par tag. Or, faire un graphe pour un tag donné alors que dans le même temps on peut changer la liste des compteurs de ce tag, ca fausse complètement le jeu... la précompilation NE PEUT PAS fonctionner
edit 2 : en fait si, ça pourrait fonctionner mais tant que je ne pré-compile que les données au niveaux des name de compteur, laissant php faire le recalcul par Tag à chaque chargement de page et ne pas précompiler cette partie.
Vous me parlez de taille de bdd. Sur ce site, de nombreux liens sont cliqués comme vous pouvez l'imaginer, à commencer par les liens de téléchargement. Ainsi, depuis Avril (début des stats) j'ai un total de 17.450 clics enregistrés pour un poids de 1,9 Mio, c'est très très peu je trouve mais bon, je peux comprendre que la taille des bdd peut être gênant pour d'autre.
Alors que fait on ?
* Perdre les données sources me semble trop risqué
* Scinder les données dans deux tables (avec une nouvelle table stat_archives par exemple) ne règle pas le pb de poids, et on n'est pas face à un ralentissement de données causé par la taille de la bdd donc mauvaise piste.
* Archiver les données sous format fichier. Je penses que c'est la moins pire des solutions.
Peu de personnes de nos jours sont limités en terme de taille de disque (<100Mo) et cela libèrerait la base de donnée.
Par contre ce n'est pas sans effet de bord puisque la génération des graphes vont prendre un coup dans l'aile niveau performance si vous continuez à générer les graphes sur une période comprenant les fichiers archives ...
Donc seconde question : gère t on le cache ? De quelle manière ?
J'ai déjà réfléchit pas mal à la question et je penses déjà avoir un début de réponse.
La génération des graphes se fait par appel Ajax / Get sur une page spécialisée.
mapage.php?param1=...¶m2=...¶m3=...
De manière très simpliste il me suffit de faire un md5 sur l'array des paramètres afin d'être capable de stocker le résultat de smarty dans un fichier de cache et/ou le charger à la prochaine demande.
Cela sera extrêmement performant sur des graphes demandés répétitivement
Cela sera complètement inutile si vous jonglez sur les dates début/fin pour le fun car je serais incapable de réutiliser le cache précédemment généré.
Si vous avez d'autres idées, des réactions ou que vous pensez que je me suis planté dans le raisonnement prévenez
Les graphes vont reposer à terme sur plusieurs axes
nombre de clic par user-agent ou par name de compteur ?
sur un cycle de 24H ? sur un cycle de 7 jours ? sur x jours ? semaines ? mois ? année ?
Soit 2 * 6 = 12 possibilités de compilation de donnée complètement différente.
Alors la solution rapide serait de pré-macher ces douzes versions, de le mettre en cache d'une manière ou d'une autre et ensuite de vider à la demande la bdd mais comment gérer le fait potentiel que dans 3 semaines après la purge on me demande un nouveau type de graphe ? c'est con de perdre nos sources non ?
edit : je viens de penser à pire : on peut regrouper ses compteurs par tag, et faire des graphes par tag. Or, faire un graphe pour un tag donné alors que dans le même temps on peut changer la liste des compteurs de ce tag, ca fausse complètement le jeu... la précompilation NE PEUT PAS fonctionner
edit 2 : en fait si, ça pourrait fonctionner mais tant que je ne pré-compile que les données au niveaux des name de compteur, laissant php faire le recalcul par Tag à chaque chargement de page et ne pas précompiler cette partie.
Vous me parlez de taille de bdd. Sur ce site, de nombreux liens sont cliqués comme vous pouvez l'imaginer, à commencer par les liens de téléchargement. Ainsi, depuis Avril (début des stats) j'ai un total de 17.450 clics enregistrés pour un poids de 1,9 Mio, c'est très très peu je trouve mais bon, je peux comprendre que la taille des bdd peut être gênant pour d'autre.
Alors que fait on ?
* Perdre les données sources me semble trop risqué
* Scinder les données dans deux tables (avec une nouvelle table stat_archives par exemple) ne règle pas le pb de poids, et on n'est pas face à un ralentissement de données causé par la taille de la bdd donc mauvaise piste.
* Archiver les données sous format fichier. Je penses que c'est la moins pire des solutions.
Peu de personnes de nos jours sont limités en terme de taille de disque (<100Mo) et cela libèrerait la base de donnée.
Par contre ce n'est pas sans effet de bord puisque la génération des graphes vont prendre un coup dans l'aile niveau performance si vous continuez à générer les graphes sur une période comprenant les fichiers archives ...
Donc seconde question : gère t on le cache ? De quelle manière ?
J'ai déjà réfléchit pas mal à la question et je penses déjà avoir un début de réponse.
La génération des graphes se fait par appel Ajax / Get sur une page spécialisée.
mapage.php?param1=...¶m2=...¶m3=...
De manière très simpliste il me suffit de faire un md5 sur l'array des paramètres afin d'être capable de stocker le résultat de smarty dans un fichier de cache et/ou le charger à la prochaine demande.
Cela sera extrêmement performant sur des graphes demandés répétitivement
Cela sera complètement inutile si vous jonglez sur les dates début/fin pour le fun car je serais incapable de réutiliser le cache précédemment généré.
Si vous avez d'autres idées, des réactions ou que vous pensez que je me suis planté dans le raisonnement prévenez