Discussion :

[chaced]

Donc c'est bien d'optimiser a mort le code, faudrait aussi que �a soit le cas du cot� du serveur

yep, mais �a c'est bien souvent l'hebergeur qui le controle.

Et puis sur un truc cod� comme un goret, le cache d'OpCode ne changera pas grand chose : phpBB est lent qu'eAccelerator soit install� ou non.

Je sens un bon gain en perf, mais j'ai un forum Skyomatic, pas de phpbb

[XtofRoland]

A vous maintenant de donner vos astuces, ou de poser des questions.

- je rajouterais unset($objet) lorsque l'on utilise des objets
- j'ai aussi pu constater que pour des requetes compliqu�es le fait de liberer le resultset accelerait considerablement le script , la toujours avec unset

Il me semble qu'un objet est lib�r� automatiquement a sa derniere utilisation...

[zaventem]

Une optimisation qui peut �galement apporter d'�norme gain de temps d'ex�ctution lors de nombreuses requetes de selection dans une base de donn�e et la mise en cache des r�sultats dans un fichier local. Le gain n'est �videmment sensible que si les donn�es s�lectionn�es �voluent peu au cours du temps. Cette astuce dans sa forme actuelle est toutefois � employer avec pr�caution car tant que le fichier cache n'aura pas �t� supprimer, cela masquera les donn�es r�ellement pr�sentes dans la base.
Dans mon cas, il s'agit d'une gallerie photo. Si elle est mise � jour toutes les semaines c'est �nhooooorme .
Pour mesurer l'ecart de performences, j'ai utilis� le bench fourni par iubito et effectu� 5000 it�rations
Voici les r�sultats que j'ai obtenu

Requete simple sur deux tables simultan�es
SELECT a.id, a.filename, a.title, a.author, a.description, a.added, b.folder FROM MySite_pictures a,MySite_albums b WHERE (a.idalbum=55 AND b.id=55) LIMIT 0,9
Dur�e: 11.16851 s, Vitesse: 448 requetes par seconde
Requete simple sur deux tables simultan�es, cache active
SELECT a.id, a.filename, a.title, a.author, a.description, a.added, b.folder FROM MySite_pictures a,MySite_albums b WHERE (a.idalbum=55 AND b.id=55) LIMIT 0,9
Dur�e: 1.48137 s, Vitesse: 3375 requetes par seconde
Requete AVEC JOIN
SELECT a.id, a.filename, a.title, a.author, a.description, a.added, b.folder FROM MySite_pictures a, MySite_albums b JOIN MySite_albums ON a.idalbum=b.id WHERE a.idalbum=55 LIMIT 0,9
Dur�e: 13.16669 s, Vitesse: 380 requetes par seconde
Requete AVEC JOIN et cache
SELECT a.id, a.filename, a.title, a.author, a.description, a.added, b.folder FROM MySite_pictures a, MySite_albums b JOIN MySite_albums ON a.idalbum=b.id WHERE a.idalbum=55 LIMIT 0,9
Dur�e: 1.30094 s, Vitesse: 3843 requetes par seconde

La diff�rence est ph�nom�nale dans mon cas, ca va entre 8 et 9 fois plus vite

Voici le code que j'ai utilis�, pour ceux que ca interesse. Il n'a subit aucune optimisation particuli�re; il devrait donc �tre encore possible d'am�liorer le r�sultat.

Code de Test

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
	echo '<h2>Requete simple sur deux tables simultanées</h2>';
	$SQL = "SELECT a.id, a.filename, a.title, a.author, a.description, a.added, b.folder 
			FROM $Table_Pictures a,$Table_Albums b WHERE (a.idalbum=$Album_ID AND b.id=$Album_ID) LIMIT $FirstPic,$galPicturesPerPage";
	echo $SQL.'<br>';
	start();
	for ($i=0; $i<5000; $i++){
	$myPictures = $myDB->Query($SQL);
	};
	stop();
	echo resultat(5000, 'requetes');
 
	echo '<h2>Requete simple sur deux tables simultanées, cache active</h2>';
	$SQL = "SELECT a.id, a.filename, a.title, a.author, a.description, a.added, b.folder 
			FROM $Table_Pictures a,$Table_Albums b WHERE (a.idalbum=$Album_ID AND b.id=$Album_ID) LIMIT $FirstPic,$galPicturesPerPage";
	echo $SQL.'<br>';
	start();
	for ($i=0; $i<5000; $i++){
	$myPictures = $myDB->Query($SQL, true);
	};
	stop();
	echo resultat(5000, 'requetes');

(Il y a la m�me chose avec la deuxieme requ�te)

La suite, le code de ma classe qui effectue la requete

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
	 /**********************************************************************
	 *	Generic SQL query.
	 ***********************************************************************
	 *	@param $query  	
	 *	@retrun : 
	 **********************************************************************/				
		function Query($query, $Cache = false){
			//Create the name of the file wich could contain the values
			$filename = $_SERVER['DOCUMENT_ROOT'].'/cache/'.md5($query).'.txt';
			if (!(strpos($query, 'SELECT') === false) && ($Cache == true) && file_exists($filename) && is_readable($filename)){
				$result = array();
				$result = $this->LoadArrayFromFile($result, $filename);
				return $result;
			} else {		
				//If there's no existing connection to the server, 
				//let's try to create one.
				if (!$this->dbConnected){ $this->Connect();};
				//If there's a connection to the server and if we can acces the 
				//database we can execute our query
				if ($this->dbConnected && $this->OpenDataBase()){
					//Construct the query
					$myQuery = $query;
					$this->LastQuery  = $myQuery;				
					if ($res = mysql_query($myQuery)){
						$result = array();
						$i = 0;
						while ($data = mysql_fetch_row($res)){
							$j = 0;
							foreach ($data as $item){
								$result[$i][mysql_field_name($res,$j)] =  $data[$j];
								$j++;
							}
							$i++;
						};			
						if (!(strpos($query, 'SELECT') === false) && ($Cache = true)){
							//Store the result in the file for the next time 
							$this->SaveArrayToFile($result, $filename);
						};		
						return $result;
					} else {
						$this->errorMessage = '<i>'.$myQuery.'</i><br/>'.mysql_error();
						$this->errorNumber = mysql_errno();
						if ($this->Debug){	$this->GetLastError();};							
					};
				};
			};
		}

ET enfin, les deux procedures que j'ai �crite pour stocker mes array dans des fichiers et les recharger par apr�s

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
	 /**********************************************************************
	 *	Save an array in a text file. An implicit conversion from each item
	 *	in the array to string must be possible otherwise it shouldn't work.
	 *	The array may contain arrays but those cannot.
	 ***********************************************************************
	 *	@param &$array : pointer to the array to store
	 *	@param $filename : name of the file where the value must be saved	
	 *	@retrun : /
	 **********************************************************************/			
		function SaveArrayToFile(&$array, $filename){
			$Header = implode(', ',array_keys($array[0]))."\r\n";
			$Content = '';
			foreach ($array as $item){
				//Pour chaque photo
				$Content .= implode(', ',$item)."\r\n";				
			};
			$handle = fopen($filename, "w+");
			fwrite($handle, $Header.$Content);
			fclose($handle);	
		}
 
	 /**********************************************************************
	 *	Load an array form a text file. An implicit conversion from string 
	 *	to the original type must be possible otherwise it shouldn't work.
	 ***********************************************************************
	 *	@param $filename : name of the file where the value has been saved	
	 *	@retrun : loaded array
	 **********************************************************************/					
		function LoadArrayFromFile($filename){
			$handle = fopen($filename, "r");
			$Text = fread($handle, filesize($filename));
			fclose($handle);	
			$Content = explode("\r\n", $Text);
			//Recuperer les index des champs
			$i = 0;
			foreach(explode(", ", $Content[0]) as $item){
				$Keys[$i] = $item;
				$i++;
			};
			$Text_Count = count($Text);
			for($i=1; $i<$Text_Count; $i++){
				$j = 0;
				foreach(explode(", ", $Content[$i]) as $item){
					$array[$i-1][$Keys[$j]] = $item;
					$j++;
				};
			};
		}			
 
	};

En modifiant ces deux derni�res fonctions pour s�rializer/des�rialiser le tableau, on perd un peu en performance mais on gagne en souplesse

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
 
	 /**********************************************************************
	 *	Save an array in a text file. 
	 ***********************************************************************
	 *	@param &$array : pointer to the array to store
	 *	@param $filename : name of the file where the value must be saved	
	 *	@retrun : /
	 **********************************************************************/			
		function SaveArrayToFile(&$array, $filename){
			$handle = fopen($filename, "w+");
			fwrite($handle, serialize($array));	//fwrite($handle, $Header.$Content);
			fclose($handle);	
		}
 
	 /**********************************************************************
	 *	Load an array form a text file. 
	 ***********************************************************************
	 *	@param $filename : name of the file where the value has been saved	
	 *	@retrun : loadded array
	 **********************************************************************/					
		function LoadArrayFromFile($filename){
			$handle = fopen($filename, "r");
			$Text = fread($handle, filesize($filename));
			fclose($handle);	
			$array = unserialize($Text);
		}			
	};

Requete simple sur deux tables simultan�es
SELECT a.id, a.filename, a.title, a.author, a.description, a.added, b.folder FROM MySite_pictures a,MySite_albums b WHERE (a.idalbum=55 AND b.id=55) LIMIT 0,9
Dur�e: 11.7862 s, Vitesse: 424 requetes par seconde
Requete simple sur deux tables simultan�es, cache active
SELECT a.id, a.filename, a.title, a.author, a.description, a.added, b.folder FROM MySite_pictures a,MySite_albums b WHERE (a.idalbum=55 AND b.id=55) LIMIT 0,9
Dur�e: 1.48182 s, Vitesse: 3374 requetes par seconde
Requete AVEC JOIN
SELECT a.id, a.filename, a.title, a.author, a.description, a.added, b.folder FROM MySite_pictures a, MySite_albums b JOIN MySite_albums ON a.idalbum=b.id WHERE a.idalbum=55 LIMIT 0,9
Dur�e: 13.24316 s, Vitesse: 378 requetes par seconde
Requete AVEC JOIN et cache
SELECT a.id, a.filename, a.title, a.author, a.description, a.added, b.folder FROM MySite_pictures a, MySite_albums b JOIN MySite_albums ON a.idalbum=b.id WHERE a.idalbum=55 LIMIT 0,9
Dur�e: 1.51247 s, Vitesse: 3306 requetes par seconde

[ackan]

Si on �crit en ligne y'a plus aucun int�r�t � faire des concat�nation, autant faire directement echo '<table><tr>...';

Parfois on pr�sente sur plusieurs lignes pour s'y retrouver dans le code PHP.

Salut

vous �tes au courant que :

echo '<table>
<tr>
<td>Contenu du td</td>
</tr>
</table>';

marche aussi tr�s bien et � mon avis est bien plus lisible que votre concat�nation de cha�ne innutile � moins qu'une variable n'intervienne dans le chmilblique ...

[divine99]

Dans une fonction, est-ce qu'on est oblig� de faire un unset � la fin de la fonction de toutes les valeurs cr��es dans la fonction si on veut que �� soit optimiser � mort OU est-ce que ces valeurs sont d'elles m�mes unset(er) d�s le moment o� l'appel � la fonction a �t� fait !

Autre question, personnellement je fais toutes mes requetes et la construction en html de la mise en forme de ces donn�es en haut de page. JE rassemble tout dans une variable $toto. Je ferme ensuite ma connexion MySQL. Et je fais un echo $toto dans le body de la page qui est d�j� pr�format�e avec un template dreamweaver. Est-ce c'est bon comme �� ?

Ensuite, apr�s le </html> je fais un unset des variables que j'ai utilis�. Est-ce utile en toute fin de page ?

Merci encore pour vos pr�cieux conseils

[Yogui]

Salut

Non, appeler unset() est inutile en fin de fonction et en fin de script : PHP s'en charge.
Parfois (souvent), il ne faut pas penser � l'optimisation d'un script (r�duire le temps d'ex�cution) mais � l'organisation du code (permettre une relecture facile).

[divine99]

Salut

Non, appeler unset() est inutile en fin de fonction et en fin de script : PHP s'en charge.
Parfois (souvent), il ne faut pas penser � l'optimisation d'un script (r�duire le temps d'ex�cution) mais � l'organisation du code (permettre une relecture facile).

Donc on a donc tout int�r�t � mettre nos traitements dans des fonctions ?

Quant � la relecture facile, tu entends pour le d�veloppeur ou simplement pour PHP ?

Autre question b�te :
si j'ai une structure de ce type:
requete1
traitement1
requete2
traitement2
requete3
traitement3

ai-je int�r�t � fermer mysql apr�s CHAQUE requ�te ? ou simplement de le faire � la fin de mon script !?!

[Yogui]

J'entends pour le d�veloppeur car PHP ne "lit" pas, il "parse".
Tu as int�r�t � mettre tes traitements r�p�t�s dans des fonctions, pas les autres.

[divine99]

J'entends pour le d�veloppeur car PHP ne "lit" pas, il "parse".
Tu as int�r�t � mettre tes traitements r�p�t�s dans des fonctions, pas les autres.

Ca je l'ai fait depuis bien longtemps �videmment !
Je parlais simplement pour optimiser des pages tr�s regard�es que j'ai besoin d'optimiser � mort (bcp de hits) notamment pour lib�rer de la m�moire.

Aurais-tu une id�e par rapport � l'exemple que j'ai donn� sur mon post pr�c�dent par rapport aux fermetures mysql_close ?

[Yogui]

Utiliser les fonctions mysql_ n'est pas une optimisation. Il y a au moins deux m�thodes plus efficaces : les extensions mysqli et pdo/pdo_mysql.

Exemple avec PDO :
http://g-rossolini.developpez.com/tu...ite-dynamique/

L�, tu gagneras en performances. Il me semble que quelqu'un nous a promis un comparatif l�-dessus mais peut-�tre me tromp�-je.

[Edit] Beaucoup de hits simultan�s ?
Est-ce que ton serveur a vraiment besoin d'�tre optimis� � fond ?
Si oui, peut-�tre serait-il int�ressant de penser � Zend Optimizer.

[jeff_!]

Utiliser les fonctions mysql_ n'est pas une optimisation. Il y a au moins deux m�thodes plus efficaces : les extensions mysqli et pdo/pdo_mysql.

Exemple avec PDO :
http://g-rossolini.developpez.com/tu...ite-dynamique/

L�, tu gagneras en performances

c'est surtout qu'a terme les extention mysql,sybase,oci_8 ne seront plus misent a jour, au profit de PDO
pour ce qui est des perfs pdo est plus rapide si on a un grand nombre de requete (prepar�es)

[psychoBob]

Je rajoute ceci:

- �vitez les "select *" lorsque vous ne devez ramener qu'une ou deux colonnes de la table.

- Mettez des index sur les colonnes qui sont souvet dans les clauses "where", bon, faut pas non plus mettre des index � tout va car pour chaque insertion, l'index doit �tre mis � jour, d'o� perte de performance. Il faut uniquement mettre des index sur des grosses tables et qui sont requ�t�es � 85% VS mise � jour.

- �vitez les variables interm�diaires inutiles

Tiens justement !
J'ai une table historique o� j'effectue pour chaque page les trois requ�tes suivantes :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
$insert="INSERT INTO `historique` 
(`idMembre`,`url`,`dateLecture`,`dateNombre`,`numero`,`titre`,`couleur`)
VALUES 
('$numeroConnexion','$retour','$dateLecture','$dateNombre','1','$titreHistorique','$couleur' )";
mysql_query($insert);
 
 
 $update = "UPDATE historique SET numero=numero+1 WHERE idmembre= '".$numeroConnexion."' ";
 mysql_query($update);
 
 
$update="DELETE FROM historique WHERE idMembre = '".$numeroConnexion."' AND numero > 100 ";
mysql_query($update);

Je n'affiche en revanche le contenu de cette table que sur une seule page dans le tableau de bord.
J'ai des index sur trois champs de la table.

Puisque tu dis qu'il y a perte de performance � chaque insert car l'index doit �tre mis � jour (pourquoi au fait?), alors est-il judicieux dans mon cas d'utiliser les index ?

[Yogui]

Salut

Si je ne m'abuse, un index est utile principalement si l'on effectue de nombreuses recherches sur la table en question (par rapport aux insertions / modifications : cf. le message de St�phane Eyskens). Dans le cas d'un historique, je doute que ce soit le cas...

Si l'index est mis � jour, c'est bien s�r parce qu'il recense tous les enregistrements de chaque champ mis � l'index. Si un tuple est ajout�, il faut mettre � jour l'index.

Tout �tait d�j� dit, je ne sais pas si je suis + clair.

[psychoBob]

Donc � te lire, je vire les index de ma table historique. Vu qu'elle enregistre 100 pages vues par membre, �a peut tr�s vite faire une table tr�s importante.
Donc qu'est ce qui va �tre le plus long ?
Ne pas mettre � jour les index mais aller chercher dans la table tous les enregistrement pour un membre ou bien mettre � jour les index et aller chercher avec un index tous les enregistrements pour un membre.
Sachant qu'en effet l'index doit �tre mis � jours � toutes les pages alors que l'historique n'est appel� qu'occasionnellement.

[Yogui]

Je vais me contenter de citer ce qui est dit juste au-dessus :

Il faut uniquement mettre des index sur des grosses tables et qui sont requ�t�es � 85% VS mise � jour.

[psychoBob]

ok, cela �tant j'ai du mal avec le jargon informatique :

requ�t�es � 85% VS mise � jour

[Yogui]

Cela signifie que les index ne sont utiles que si la proportion "requ�tes de s�lection" par rapport aux "requ�tes d'insertion et de mise � jour" est de 85% par rapport � 15%.

Il faut donc que tu cherches davantage que tu ne modifies la table. Ce n'est pas ton cas.

[Sergejack]

Est-ce qu'on peut optimiser ce sujet ?
Il est trop lourd � charger dans ma RAM grise.

[Blustuff]

J'ai un r�sum� tr�s simple : "Pour optimiser, il faut d'abord chercher ce qui est lent dans un programme, identifier les goulots d'�tranglement". Ce r�sum� rends miraculeusement 90% de ce topic d'int�r�t tr�s faible : on conna�t des solutions meilleures que d'autres mais dont l'application fait perdre en lisibilit� contre des performances ne d�passant rarement les 1% d'am�lioration. Parmi les conseils vraiment utiles, on peut citer Yogui en derni�re page :

Parfois (souvent), il ne faut pas penser � l'optimisation d'un script (r�duire le temps d'ex�cution) mais � l'organisation du code (permettre une relecture facile).

Et une URL :

http://phplens.com/lens/php-book/opt...ugging-php.php

______
Fin du r�sum� : D (� compl�ter �videment, ce s'rait un travail int�ressant, mais tr�s long)

Il y avait des interventions int�ressantes, mais c'est vrai que tout relire... Tous ce qui concerne l'optimisation des requ�tes sur une base de donn�e est quasiment utile, mais il faudrait certainement se r�f�rer au forum correspondant � la BDD utilis�e. Il y en a beaucoup � prendre avec des pincettes. Genre, les calculs de temps d'execution en oubliant le temps de parsing. Et certaines solutions d�sign�es comme "mauvaises" sont plus rapides � parser que les "bonnes" solutions. Ce qui revient � dire que le gain se fait uniquement dans des conditions de r�p�tions, ou quand un cache d'opcode est activ�. (Certains utilisent les optimisations, voir les conseillent dans leur signature, dans des cas qui sont hors de ces conditions) Cet exemple illustre bien la complexit� de l'optimisation, quelque soit le langage d'ailleurs, et que l'on perd souvent beaucoup trop de temps � essayer d'optimiser pour des r�sultats ridicules voir insignifiants. (Et comme le dit implicitement Yogui � d�truire la lisibilit� du code) Gagner des microsecondes sur des scripts qui s'executent en des temps de l'ordre de la centaine de milliseconde ce n'est pas int�ressant.


Il y a des �tudes d'optimisation de script qui peuvent �tre efficaces avec les bons outils. On peut programmer ces outils soit m�me, en php : l'astuce est donn�e dans une page assez inconnue du manuel php :

http://www.php.net/manual/fr/control...es.declare.php

Avec une poign�e de lignes, on peut calculer le temps d'execution d'un script ligne par ligne : on peut mesurer avec une marge d'erreur raisonable le temps que la machine passe sur chaque ligne, ce qui permet d'identifier au premier coup d'oeil ce qui prends du temps dans un code php, quelles fonctions, quelles lignes, en rapport avec le temps total d'ex�cution, y compris le temps pass� dans un include pour r�cup�rer le temps de parsing. A partir de l�, on peut identifier les segments de code lents et seulement alors tenter de les optimiser.

[ePoX]

En termes plus pratiques un truc qui n'� pas �t� que peu abord� c'est la mise en cache des objets durant l'execution, c'est plutot pour php5.
zaventem en � un peu parl� sur un cas extr�mement particulier.

Bref, sa arrive souvent qu'un objet soit construit plusieurs fois pour une m�me repr�sentation en base.

Un exemple simple serait le cas d'une liste de produit ave des marques.
Chaque objet produit pourrait avoir en son sein une r�f�rence vers une marque.
Hors il arrive souvent qu'une marque appartiennent � de multiples produits diff�rent.
Ce qui, si l'on y fait pas attention, instanciera 20 objet de la marque toto.

en cons�quence on obtient :
- Une rupture entre l'unicit� de la marque en base, et l'unicit� de la marque lors de sa transofmation en objet.
- Alourdit betement l'application qui execute N requetes identique pour le m�me objet.

Pour �viter ces pertes idiotes une bonne solution est de cr�er une petite classe de cache... et d'instancier ces objets au travers de m�thodes statique. A bas le new Produit( $id );

En code sa donne :

Code m�thode gourmande :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
 
class produit
{
	public $nom;
	public $marque;
 
	public function __construct( $id )
	{
		$sql = "SELECT * FROM ...";
		$query ....
		$res....
 
		$this->nom = $res["nom"];
		$this->marque = new Marque( $res["idmarque"]);
	}
}
 
class Marque
{
	public $id;
	public $nom;
 
 
 
	public function __construct( $id )
	{
		$sql = "SELECT * FROM ...";
		$query ....
		$res....
 
		$this->id = $res["id"];
		$this->nom = $res["nom"];
	}
}

Ou bien :

Code m�thode plus l�g�re :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
 
class produit
{
 
	public $nom;
	public $marque;
 
	public function __construct( $id )
	{		
		$this->nom = NULL;
		$this->marque = NULL;
	}
 
	public static function lire( $id )
	{
		$objet = Cache::Get( __CLASS__."lire".$id );
		if( $objet != NULL )
			return $objet;
 
		$objet = new Produit();
 
		$sql = "SELECT * FROM ...";
		$query ....
		$res....
 
		$objet->nom = $res["nom"];
		$objet->marque = Marque::lire( $res["idmarque"]);
 
		 Cache::Put( $objet , __CLASS__."lire".$id );
 
		return $objet;
	}
}
class Marque
{
 
	public $id;
	public $nom;
 
	public function __construct( $id )
	{		
		$this->id = NULL;
		$this->nom = NULL;
	}
 
	public static function lire( $id )
	{
		$objet = Cache::Get( __CLASS__."lire".$id );
		if( $objet != NULL )
			return $objet;
 
		$objet = new Marque();
 
		$sql = "SELECT * FROM ...";
		$query ....
		$res....
 
		$objet->id = $res["id "];
		$objet->nom = $res["nom"];
 
		 Cache::Put( $objet , __CLASS__."lire".$id );
 
		return $objet;
	}
}

Et le petit bout de code qui va bien pour sauvegarder/lire des objets en cache :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
 
//////////////////////////////////////////////////////////
///	\class Cache
///	Classe qui permet de mettre en mémoire des objets, puis de les récupérer
//////////////////////////////////////////////////////////
class Cache
{
 
	//////////////////////////////////////////////////////////
	//	propriétés
	//////////////////////////////////////////////////////////
	private static $Cache = array();
 
	//////////////////////////////////////////////////////////
	///	constructeur
	//////////////////////////////////////////////////////////
	private function __construct()
	{
	}
 
	//////////////////////////////////////////////////////////
	///	Mets en un objet en cache
	///	l'uoid (Unique Object ID) est un identifiant unique
	//////////////////////////////////////////////////////////
	public static function Put( $Object , $uoid )
	{
		if($Object == NULL)
			return false;
		if( $uoid == NULL)
			return false;
 
		self::$Cache[$uoid] = $Object;
 
		return true;
	}
 
	//////////////////////////////////////////////////////////
	///	Recherche un objet en cache
	///	l'uoid (Unique Object ID) est un identifiant unique
	//////////////////////////////////////////////////////////
	public static function Get( $uoid )
	{
		if( isset( self::$Cache[$uoid] ) )
			return self::$Cache[$uoid];
		return NULL;
	}
 
	//////////////////////////////////////////////////////////
	///	destructeur
	//////////////////////////////////////////////////////////
	public function __destruct()
	{
	}
}

Je me suis permit de poster cela car j'ai vu assez souvent sur le forum des forumeurs qui faisait cela : new Produit( $id ); ce qui me laisse pens� que ce que je viens d'exposer pourrait les aider � ne plus executer de requetes inutiles.

voilou,

bbye