Optimisation de scripts PHP/MySQL

Je rajoute un lien discut� tr�s recemment qui concerne �galement ce topic
http://www.developpez.net/forums/d12...njections-sql/

++

Un petit ajout concernant l'optimisation des scripts php.
Au lieu d'utiliser la fonction in_array il faudrait mieux utiliser isset(tab[index]) cvd rechercher sur l'index au lieu de la valeur.

Bonjour,

in_array n'a pas du tout la m�me s�mantique.

in_array �a revient � faire

Code:

---

1 2 3 4 5 6 7 8 9 10 11

function chercher($valeur) { $trouve = false; for($index=0; $index < $tab.length(); $index++) { if($tab[$index] == $valeur) { $trouve = true; } } return $trouve; }   cherche('valeur cherchée');

---

Alors que isset($tab[$index]) ne v�rifie pas que 'valeur cherch�e' est dans le tableau, mais simplement qu'il existe une entr�e dont on ne connait pas la valeur � l'index dans le tableau.

On peut donc toujours utiliser une boucle PHP pour chercher dans un tableau. Mais ce sera toujours moins optimal que d'utiliser une fonction native C++ compil�e dans le noyau.
A+JYT

Bonjour tout le monde,

Je me poses deux questions relatives � l'optimisation de PHP/MySQL:

1) hachesse a dit ceci :

Citation:

---

Envoy� par hachesse

Ouvir 1 seule connection � la base de donn�e et la ferm�e � la fin de la page, preferer le connect au pconnect

---

C'est pas mieux de se connecter/d�connecter pour chaque requ�te une fois qu'on a r�cup�rer les valeurs pour peu que les requ�tes soient espac�es les unes des autres ?

2) Lorsqu'on fait une boucle, vaut-il mieux stocker en variable pour tout afficher une fois la boucle termin�e ou afficher au fur � mesure ?

Exemple :

Code:

---

1 2 3 4 5 6 7 8 9 10

// Tout afficher d'un seul coup while ($row = @mysql_fetch_assoc($sql)) { $var .=$row[col1]; } echo $var;   // Afficher au fur et à mesure while ($row = @mysql_fetch_assoc($sql)) { echo $row[col1]; }

---

Merci beaucoup pour ce sujet tr�s int�ressant et pour toutes r�ponses � mes questions !

Citation:

---

Envoy� par King Bradley

C'est pas mieux de se connecter/d�connecter pour chaque requ�te une fois qu'on a r�cup�rer les valeurs pour peu que les requ�tes soient espac�es les unes des autres ?

---

Une connexion prend plus de temps qu'une simple requete, donc avec 3 SELECT, tu vas multiplier ton temps par 4(ou plus) sur une page

Citation:

---

pour peu que les requ�tes soient espac�es les unes des autres

---

Il faut combien de temps � php pour ex�cuter 50 lignes de code entre tes requ�tes ? php est rapide :)
Et si tu as 1000 personnes de connect�es sur ton site :aie: le serveur se prend 3000 connexions en 2 secondes ! et m�me si tu espaces tes requ�tes :)

Citation:

---

Envoy� par King Bradley

2) Lorsqu'on fait une boucle, vaut-il mieux stocker en variable pour tout afficher une fois la boucle termin�e ou afficher au fur � mesure ?

---

La vitesse est la m�me, simplement dans un cas tu consommes de la m�moire, alors que dans l'autre c'est n�gligeable. On ne choisit la structure gloutonne, voire dangereuse, uniquement si elle est n�cessaire.

Merci beaucoup pour ces r�ponses claires et pr�cises ;)

Citation:

---

Envoy� par King Bradley

Bonjour tout le monde,

Je me poses deux questions relatives � l'optimisation de PHP/MySQL:

1) hachesse a dit ceci :



C'est pas mieux de se connecter/d�connecter pour chaque requ�te une fois qu'on a r�cup�rer les valeurs pour peu que les requ�tes soient espac�es les unes des autres ?

2) Lorsqu'on fait une boucle, vaut-il mieux stocker en variable pour tout afficher une fois la boucle termin�e ou afficher au fur � mesure ?

Exemple :

Code:

---

1 2 3 4 5 6 7 8 9 10

// Tout afficher d'un seul coup while ($row = @mysql_fetch_assoc($sql)) { $var .=$row[col1]; } echo $var;   // Afficher au fur et à mesure while ($row = @mysql_fetch_assoc($sql)) { echo $row[col1]; }

---

Merci beaucoup pour ce sujet tr�s int�ressant et pour toutes r�ponses � mes questions !

---

1) attention pconnect c'est gr�ce � lui qu'on a sur les site avec MYSQL derri�re des "Too many connections in ..." en effet le pconnect ne ferme pas les connexions mais normalement les restitues pour la r�utiliser. il s'agit d'un pool de connexions mais on ne ma�trise pas le nombre c�t� client d'o� des pb.

2) moins on ouvre et ferme les connection mieux c'est.

3) c'est tout le probl�mes des pattern en couche. en th�orie la couche pr�sentation ne doit pas avoir acc�s � la couche m�tier (uniquement au contr�leur) le contr�leur ne devrait donner que des valeur � la couche pr�sentation et pas d'objet m�tier.
l'objet m�tier lui-m�me ne doit pas acc�der � la persistance mais passer par le service d'acc�s au donn�e DAO. le DAO ne doit pas donner d'objet de persistance � la couche m�tier.
voil� pour la th�orie. il en r�sulte que lorsque ta requ�te � remont� les donn�es elle doit donner ces donn�es � l'objet m�tier. mais ne doit pas lui fournir les �l�ment de persistance. donc normalement l'objet m�tier ne peut voir le resultset.
il en r�sulte que la seule solution est de placer les donn�es en m�moire hors du resultset.
c'est pourquoi souvent on vois dans ces archies le DAO parcourir le resultset pour alimenter un objet m�tier.
mais lorsque le contr�leur r�cup�re � sont tour l'objet m�tier il ne doit pas le donner � la couche pr�sentation. l� encore on n'a pas le choix si on respecte la th�orie les donn�es sont sortie de l'objet m�tier pour �tre plac� dans la vue.

tout ceci est consommateur d'espace et de temps. les frameworks s�arrangent plus ou moins avec la th�orie.
une solution fr�quente consiste � cr�er un dataobjet (objet sans m�thode juste des membres). le DAO extrait les data du resultset et le mets dans le dataobjet. il donne ensuite une r�f�rence � l'objet m�tier. celui-ci garde la r�f�rence et l'encapsule. on vois alors les membre comme s'il �tait ceux de l'objet m�tier. le contr�leur � sont tour passe cette r�f�rence � la vue. la vue peux donc acc�der au data mais pas manipuler les m�thodes m�tier. l'honneur est sauf.
enfin presque car si la vue change une valeur l'objet m�tier et modifi�. en effet la vue poss�de la m�me r�f�rence que l'objet m�tier sur le dataobjet. ce n'est donc pas parfait.

l'optimal en terme de temps et d'espace est de donner directement le resultset � la vue. en effet on ne lit le contenu du r�sultset que lorsqu'on l'utilise r�ellement. mais du coup plus e couche plus de m�tier plus de contr�le.

enfin in existe bien des optimisations interm�diaire pour ce probl�me. et le mieux est de connaitre les patterns existant et de comprendre leurs objectifs, leurs contraintes, leur champs d'applications, pour faire le bon choix en toute connaissances.

A+JYT

1/ Donc concernant l'ouverture/fermeture des connections on peut �tre affirmatif, et retenir que "moins on ouvre et ferme la connection et mieux c'est" car ce processus prend un temps non n�gligeable.

2/ Par contre concernant le fait d'enregistrer le contenu du r�sultat dans une variable (souvent un tableau), c'est plus discutable. Outre le fait que cela permet de lib�rer plus vite la ressource de la requ�te, on le fait aussi tr�s souvent pour des pb d'organisation de code comme indiqu� par sekaijin. Sur le principe c'est tr�s optimis� c�t� serveur bdd mais �videmment moins c�t� php qui doit passer par la cr�ation d'un tableau et donc consommer du temps et de la m�moire. Donc suivant les configurations de code mais aussi et surtout suivant la grandeur du tableau, on pourra choisir d'afficher directement la ressource plut�t que de passer par un tableau ou un objet interm�diaire. Mais � la diff�rence de papajoker (si j'ai bien compris sa r�ponse) et notamment pour les raisons indiqu�es par sekaijin, je dirai que c'est plut�t assez rare et qu'on � tendance � privil�gier aujourd'hui la structure "gloutonne" c�t� php. Enfin bon tu vois que les r�ponses peuvent varier suivant les crit�res et le code que l'on consid�re et l'on ne peut pas �tre aussi cat�gorique que pour ta premi�re question.

Oui, je vois �a ^^

Merci � vous trois pour ces r�ponses !