Problématique optimisation accès bdd mysql ...

WRInaute accro
Problématique : Je suis en train de gérer les compteurs "nombre de vus" de chaque topic dans mon petit forum "maison" ... et donc si je la joue à la bucheronne et que durant un temps donné d'une minute il y a 20 personnes sur le forum et que chacune ouvre 5 topic, ca nous fait 20 x 5 = 100 (je sais je compte bien :mrgreen: ) accès à la base pour faire + 1 dans des compteurs :?

Optimisation : J'ai donc adopté le principe suivant :

1 - A chaque lecture d'un topic par un visiteur, je ne fait que cela :

Code:
<?php
$chemin=$_SERVER["DOCUMENT_ROOT"]."/".$datasout."/FORUM/compteur_vus.txt";
$valeur=$valeur.$topic_numero."\n";
$refdoc = fopen ($chemin, "a+");
fputs ($refdoc, $valeur);  
fclose ($refdoc);	
?>

Bref j'empile dans un document .txt (hé hé chassez le naturel ... :mrgreen: ) une succession de numéros de topic. A ce stade j'ai donc gardé la trace que tels et tels topics ont été vus mais je n'ai pas mis à jour la base de donnée (partant du principe que pour cette info, un absolu temps réel ne présente aucun caractère indispensable - c'est un choix).

Mon doc txt a donc l'allure suivante a un instant T :

Code:
123
45
17
123
123
123
17
45

2 - En fait le script se poursuit par un second bout de code qui ne va être executé qu'une fois par minute (voir moins) et qui va traiter la file d'attente en comptant le nb de vus par topic et en allant mettre a jour chaque topic une seule fois (meme si il a été ouvert 15 fois depuis le dernier traitement de la file d'attente).

Et donc le script complet que j'execute à chaque ouverture de topic est finalement :

Code:
<?php

$topic_compteur_seuil=10; // a remonter avec un chiffre variable selon trafic - 10 c'est pour mes tests)

// entrée : $topic_numero
// en sortie : On ajoute le numero de topic a la liste des vus en attente


// ========== Ajout du topic a la file d'attente des nb vus

$chemin=$_SERVER["DOCUMENT_ROOT"]."/".$datasout."/FORUM/compteur_vus.txt";
$valeur=$valeur.$topic_numero."\n";
$refdoc = fopen ($chemin, "a+");
fputs ($refdoc, $valeur);  
fclose ($refdoc);

// ========== Intégration ** éventuelle ** de la file d'attente à la bdd

$ze_ss=intval(date('s'));
if($ze_ss <= 2) // On ne se pose la question que si les secondes sont entre 0 et 2
{
	$tab_work=array();
	$tab_work=file($chemin); // on recupère la file d'attente
	if($sizeof($tab_work) > $topic_compteur_seuil) // on ne traite que si le tableau a atteint le seuil sinon on traitera le prochain coup
	{
		// ----- reinit du .txt ($tab_work contient déjà la file d'attente a traiter)
		$refdoc = fopen ($chemin, "w+");
		fputs ($refdoc, "");  
		fclose ($refdoc);

		// ----- traitement des comptages en attente
		asort($tab_work);
		$last_num=$tabwork[0];
		$work_nb_vus=0;
		
		include("sql_base_open.php");
		foreach($tabwork as $work_num)
		{
			if($work_num == $last_num) { $work_nb_vus++; }
			else
			{
				// ----- maj bdd avec + $work_nb_vus sur $last_num
				include("sql_topic_compteur_vu_add.php");
				
				// ----- on poursuit la boucle avec topic suivant
				$last_num=$work_num;
				$work_nb_vus=0;
			}
		}
		include("sql_base_close.php");
	}
}

?>

Note : ce code est brut de fonderie (pas encore mis en service ni testé) donc peut être des coquilles de frappe mais c'est le pricnipe qu'il faut regarder

Résultat : si les 100 ouvertures de topic n'ont en fait concerné que 5 topics (ce qui sera souvent le cas puisque en génarl on est tous sur les topics vivants), il y aura 5 requetes de mise a jour au lieu de 100 ... pour au final le même résultat : le nb de vus par topic à jour ...

Bon certes c'est du pinaillage mais au final de pinaillages en pinaillages ... ca fait de la ressource consommée en moins et donc libérée pour autre chose :wink:

Question : Est-ce que vous voyez des trucs a optimiser dans mon code ou mon approche ? ou carrément avoir une autre approche ?
 
WRInaute accro
L'accès à une donnée d'un fichier est plus lent qu'à la base de données =D Donc tu fais tout ça pour rien. ^^ C'est pas des centaines de petites requêtes de même type qui va ralentir la base. Elle a ses propres mécanismes pour repérer les requêtes similaires et accèdera au contenu très rapidement.

Tu réinventes la roue tu vois j'tai dit :mrgreen:
 
WRInaute accro
+1 + declencher le script en ajax pour ne pas gêner le surf si vraiment un jour la base à un ralentissement
 
WRInaute accro
YoyoS a dit:
L'accès à une donnée d'un fichier est plus lent qu'à la base de données =D
Tu es certain de cela ? qu'un update est plus rapide qu'un put sur txt ?

YoyoS a dit:
Donc tu fais tout ça pour rien. ^^ C'est pas des centaines de petites requêtes de même type qui va ralentir la base. Elle a ses propres mécanismes pour repérer les requêtes similaires et accèdera au contenu très rapidement.
Oui je me suis posé la question mais comme je je connais pas encore assez bien mysql, je ne sais pas trop comment il gère ses caches lectures et ses caches ecriture ...

Donc pour toi je me casse pas le fion : + 1 je vais faire l'update direct et basta (d'autant plus que si +1 je viens pas definition de lire le record pour récupérer les datas ...) ?
 
WRInaute impliqué
Un serveur de base de données est conçu pour stocker des données. S'il n'est pas capable de traiter une simple requête du genre :
Code:
UPDATE table SET nombre_vus = nombre_vus+1 WHERE id = 154
Bah, on repasse tous en fichier texte :D

De plus, non seulement l'accès écriture/lecture sera moins rapide, mais tu fais comment pour gérer l'accès concurrencé (peut-être pas le bon mot) ? Entre la lecture et l'écriture du fichier, une autre personne peut lire ce fichier, tu te retrouveras avec un contenu erroné. La solution sera de locker la fichier durant l'accès, mais dans ce cas, tu ralenti encore plus le traitement des informations.

Clairement, laisse tomber tous ce qui est fichier texte et fait du full BDD. 100 requêtes pour une base de données, ce n'est rien du tout.
 
WRInaute accro
oki oki je laisse béton ... ma fausse bonne idée ... :wink: Un simple update et on en parle plus
 
Discussions similaires
Haut