Statistiques Boinc -Stats de l'AF (Jump, BZH, Seb, Ivan et les autres)

[pas93]

Ce serait plutot une page statique en cache qu'il faudrait.

[BlackStar95]

ce qui consomme le plus c'est MySQL .Or le cache MySQL garde en cache le résultat des requêtes les plus utilisées  
donc comme le script PHP n'est la que pour afficher la BDD de façon à être compréhensible par un humain, c'est comme si la page était en cache
après on peut faire la même chose avec une page sauf que ça gache le fait d'utiliser PHP ---> c'est plus (ou presque plus ) dynamique  
n'empêche, c'est pas bête comme idée, par contre, il faudrait se contenter de mettre en cache les premières pages, sinon il y aurait un problème avec la RAM (je pense  :sweat: ) :ouch:
ou sinon le script PHP génèrerais un fichier html en dur sur le DD sauf que y aurait tellement de page à produire que sa pourrirait les accès au disque pendant la duré de la màj des stats  (et donc l'hébergeur serait toujours pas content  :whistle: ):sweat:
 

[MarcP]

Le cache de MySQL est assez merdique et dépends de pas mal de paramètres

[BlackStar95]

il parait que c'est pas efficace avec les forums  
après je dit ça, j'dit rien hein ...

 :whistle:

[pas93]

ce qui consomme le plus c'est MySQL .Or le cache MySQL garde en cache le résultat des requêtes les plus utilisées  
donc comme le script PHP n'est la que pour afficher la BDD de façon à être compréhensible par un humain, c'est comme si la page était en cache
après on peut faire la même chose avec une page sauf que ça gache le fait d'utiliser PHP ---> c'est plus (ou presque plus ) dynamique  
n'empêche, c'est pas bête comme idée, par contre, il faudrait se contenter de mettre en cache les premières pages, sinon il y aurait un problème avec la RAM (je pense  :sweat: ) :ouch:
ou sinon le script PHP génèrerais un fichier html en dur sur le DD sauf que y aurait tellement de page à produire que sa pourrirait les accès au disque pendant la duré de la màj des stats  (et donc l'hébergeur serait toujours pas content  :whistle: ):sweat:
 

Eu moi je parle pas d'un cache Mysql mais bien d'un cache en HTML, comme le fait spip pour le site de EDLS, et celà marche super bien. Après je ne voit pas comment surcharger le DD, puisque pour un serveur les DD sont très performants, et les mises à jour ne se font pas tous en même temps mais à un interval de 2 à 3 minutes, et pendant la nuit. Je ne voit pas comment ça peut saturé l'ordi vue que il y aura besoin de la même moulinette, sauf que la base SQL ne sera utilisé que une seul fois vue que la page créer en HTML au lieux de l'envoyé sur le navigateur web, elle sera envoyé sur le cache, et nous on consultera se cache.  C'est comme si la moulinette d'oxxam on fesait un screen et que on le méttais sur le serveur et que l'on consultait le screen. En plus en fesant un cache HTML par jour on pourrait gardé un historique.

[MarcP]

Eu moi je parle pas d'un cache Mysql mais bien d'un cache en HTML, comme le fait spip pour le site de EDLS, et celà marche super bien. Après je ne voit pas comment surcharger le DD, puisque pour un serveur les DD sont très performants, et les mises à jour ne se font pas tous en même temps mais à un interval de 2 à 3 minutes, et pendant la nuit. Je ne voit pas comment ça peut saturé l'ordi vue que il y aura besoin de la même moulinette, sauf que la base SQL ne sera utilisé que une seul fois vue que la page créer en HTML au lieux de l'envoyé sur le navigateur web, elle sera envoyé sur le cache, et nous on consultera se cache.  C'est comme si la moulinette d'oxxam on fesait un screen et que on le méttais sur le serveur et que l'on consultait le screen. En plus en fesant un cache HTML par jour on pourrait gardé un historique.

Disons que créer 20 000 fichiers, ca prends du temps, et la stocker, ca prends de la place. La DB ne sera pas utilisé qu'une seule fois dans la mesure où un scrit PHP ne peut s'executer + de 30 secondes.
C'est un peu plus complexe et c'est un joyeux souk à coder

[pas93]

Ce dont je veut parler c'est le pure cache HTML, celui-ci:


[cpp]ici code php que vous ne voulez pas mettre en cache
$urldemandee=$_SERVER['REQUEST_URI']; //on lit l'adresse de la page
$urldemandee=ereg_replace('/','-',$urldemandee); // on tranforme l'adresse en nom de fichier
if($urldemandee=="-") $urldemandee="-index.html"; // si l'adresse est la racine du site, on ajoute index.html
$fichierCache="cache/cache".$urldemandee; // on construit le chemin du fichier cache de la page
if (@filemtime($fichierCache)   ob_start(); // on démarre la bufferisation de la page: rien de ce qui suit n'est envoyé au navigateur
?>
Votre page PHP ici
   $contenuCache = ob_get_contents(); // on recuperre le contenu du buffer
   ob_end_flush();// on termine la bufferisation
   $fd = fopen("$fichierCache", "w"); // on ouvre le fichier cache
   if ($fd) {
      fwrite($fd,$contenuCache); // on ecrit le contenu du buffer dans le fichier cache
      fclose($fd);
     }
} else { // le fichier cache existe déjà
  include ($fichierCache); // on le copie ici
}
?>[/cpp]

Ce script n'es pas de moi, ( mon niveaux est encore trop bas mdr ) par contre il faudrait changer le
if (@filemtime($fichierCache)  Après je ne suis pas un expert en PHP Mysql, mais Spip lui utilise en plus ( je vient de le prendre dans le code de ma page Spip )  || isset($_GET['recalcul']))  Car il y a juste à appuyé sur le bouton.

En gros, je parle de refaire marcher la moulinette exactement comme elle marchait de oxxam, sauf que elle se mettrais en cache.

[oXXam]

il n'en demeure pas moins que ton cache finit quand meme en page statique ($fichiercache) stocké sur le DD du serveur. l'avantage coté prog, c'est que j'ai qu'un seul fwrite pour toute la page.

[MarcP]

Ce dont je veut parler c'est le pure cache HTML, celui-ci:

En gros, je parle de refaire marcher la moulinette exactement comme elle marchait de oxxam, sauf que elle se mettrais en cache.

Ca ne change rien :
Disons que créer 20 000 fichiers (de pure cache HTML ), ca prends du temps, et la stocker, ca prends de la place. La DB ne sera pas utilisé qu'une seule fois dans la mesure où un scrit PHP ne peut s'executer + de 30 secondes.
C'est un peu plus complexe et c'est un joyeux souk à coder

[pas93]

Ca ne change rien :
 La DB ne sera pas utilisé qu'une seule fois dans la mesure où un scrit PHP ne peut s'executer + de 30 secondes.
C'est un peu plus complexe et c'est un joyeux souk à coder

Eu tu à écrit exactement la même choses un peu plus haut l'age arrive vite ?     Juste un truc quand je dit une seul foit, c'est à dire que le besoin qu'il y a besoin ne se fera que une seul foi ^^ Après oui par contre c'est vrais que ça doit faire énormément de demande de place.

[MarcP]

Eu tu à écrit exactement la même choses un peu plus haut l'age arrive vite ?     Juste un truc quand je dit une seul foit, c'est à dire que le besoin qu'il y a besoin ne se fera que une seul foi ^^ Après oui par contre c'est vrais que ça doit faire énormément de demande de place.

Ben t'as pas tenu compte de mon message plus haut du coup j'ai juste copié-collé

[Cthulhu22]

@MarcP> explique toi.
La BD ne sera utiliser qu'une seule fois pour afficher une page donnée, pas le site en entier (une fois pour chaque page différente).

Et je ne comprend pas bien l'histoire des 30 secondes.

[MarcP]

En fait ca va augmenter la charge de faire ca, car les gens regardent les stats détaillés...qui sont différentes.
Le cache ca marche bien pour des sites portails (meme page affichée plein de fois)
De plus :
-Chargement du script (1 accès disque)
-Vérif du cache (1 accès disque)
-Effacement du cache(1 accès disque)
-Recherche en DB (2 accès disque)
-Ecriture sur disque(2 accès disques)
C'est pas le mieux en opti quand on sert plein de pages différentes !

[pas93]

Oui mais la 1 and 1 leur problème c'est la BDD pas l'accès au disque non ?

Au faite juste petite questions que j'aimerais te posé, car c'est exactement dans ton métier ^^.

Les tous nouveaux Serveur sont en Sata 2 avec des disques durs dans les 12800 tours ? Ou ce n'es pas encore la norme pour tous les nouveaux serveur, ou alors il y a une norme encore mieux ^^

[oXXam]

Pour générer ma page statique, je me retrouve donc avec deux options :
-écriture ligne par ligne avec du fwrite à profusion
- bufferiser la page et l'écrire en une seule fois.
coté charge serveur, y a t'il une préférence ?

[Cthulhu22]

C'est justement pour cela qu'il suffit d'appliquer ce système pour les pages très souvent regardée (on voit facilement lesquelles, sinon un simple compteur et hop !)

Si tu fais cela pour quelques pages (une dizaine), tu devrais y gagner largement sur le plan accès à la BD et perdre assez peu en accès disque (tu fais la création une seule fois, et après ce ne sont que des lectures d'un fichier sur le disque au lieu d'une requete SQL couteuse)

@oxxam> aucune idée (je dirais la deuxième solution)

[MarcP]

Oui mais la 1 and 1 leur problème c'est la BDD pas l'accès au disque non ?

Au faite juste petite questions que j'aimerais te posé, car c'est exactement dans ton métier ^^.

Les tous nouveaux Serveur sont en Sata 2 avec des disques durs dans les 12800 tours ? Ou ce n'es pas encore la norme pour tous les nouveaux serveur, ou alors il y a une norme encore mieux ^^

Tu peux avoir des disques pourri ou le dernier cri scsi en fibre optique, ca dépends de tes besoins. Mes serveurs ont pas des supers disques dur, du sata comme tu en as dans ton PC, car ce que j'héberge tiens dans la RAM de chaque serveur (4 à 8Go)

[MarcP]

Pour générer ma page statique, je me retrouve donc avec deux options :
-écriture ligne par ligne avec du fwrite à profusion
- bufferiser la page et l'écrire en une seule fois.
coté charge serveur, y a t'il une préférence ?

Le mieux est de bufferiser. Mais de toute facon, fwrite bufferise de lui meme de manière + ou - efficace.

[pas93]

Tu peux avoir des disques pourri ou le dernier cri scsi en fibre optique, ca dépends de tes besoins. Mes serveurs ont pas des supers disques dur, du sata comme tu en as dans ton PC, car ce que j'héberge tiens dans la RAM de chaque serveur (4 à 8Go)

tu n'héberge que 4 à 8 go par serveur ? lol Tu veut dire que il n'y a que 4 à 8 go qui sont très souvent appeler ?

Ps: Pour le site de stats, tu va donc être héberger chez MarcP ??  Ou tu va revoir ton code ? Le site remarche c'est déjà le plus important, mais le truc qui manque aussi un peu c'est de voir les membres d'un Mt, en plus l'ancienne moulinette, avait vraiment un confort de navigation exelent, ont pouvais presque tous savoir sur les stats de notre AF.

[guillaumeb86]

  Oxxam
Voici deux liens à rajouter pour la MT Poitou-Charentes :
le site : http://www.boinc-af.org/content/view/433/185/
le forum : http://www.boincfrance.org/modules/newbb/viewforum.php?forum=112
merci d'avance

Sinon, serait-il envisageable de créer des sous-classements ? Cela pourrait être utile pour faire un classement d'univertés ou de MT d'équipes de football par exemple.

[oXXam]

Pour obtenir un sous-classement, il faut pouvoir différencier ces miniteams des autres. Pour les miniteams de la team EST, j'ai donc créé une table qui  répertorie ces miniteams. Je peux faire la meme chose avec d'autres themes. Simplement, la mise à jour de ces tables n'est pas dynamique. Je dois rajouter les nouveaux éléments manuellement. A part ça, c'est possible.

[guillaumeb86]

Dans ce cas là, je trouve qu'un classement de pays et des régions françaises seraient intéressant

[MarcP]

tu n'héberge que 4 à 8 go par serveur ? lol Tu veut dire que il n'y a que 4 à 8 go qui sont très souvent appeler ?

Ps: Pour le site de stats, tu va donc être héberger chez MarcP ??  Ou tu va revoir ton code ? Le site remarche c'est déjà le plus important, mais le truc qui manque aussi un peu c'est de voir les membres d'un Mt, en plus l'ancienne moulinette, avait vraiment un confort de navigation exelent, ont pouvais presque tous savoir sur les stats de notre AF.

Ben tu sais du code ca prends pas de place.
Par exemple, le forum complet (code, images, avatars, etc) tiens dans 172Mo

Après t'as des trucs genre images sur des boutiques de e-commerce, mais les grandes images ca représente un trafic négligeable !

[pas93]

Ha ok, mais sur un serveur il peut cohabiter plusieurs 100ène de site, donc seulement 4 à 8 go c'est peu. Ce sont donc les pages les plus utilisés qui sont sur la ram non ?

[MarcP]

j'ai pas des centaines de sites/serveur, de plus sur un serveur généralement t'as que 3-4 gros sites, la plupart sont très peu consultés