Je rajoute un lien discuté très recemment qui concerne également ce topic
http://www.developpez.net/forums/d12...njections-sql/
++
Je rajoute un lien discuté très recemment qui concerne également ce topic
http://www.developpez.net/forums/d12...njections-sql/
++
_______________________________________
Azure Data Engineer & Azure DBA
Blog TSE sur developpez.com : Architectures web hautes performances en PHP
Les meilleurs tutoriels PHP sur developpez.com
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 php : Sélectionner tout - Visualiser dans une fenêtre à part
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 :
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 :
Merci beaucoup pour ce sujet très intéressant et pour toutes réponses à mes questions !
Code : Sélectionner tout - Visualiser dans une fenêtre à part
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]; }
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
Il faut combien de temps à php pour exécuter 50 lignes de code entre tes requêtes ? php est rapidepour peu que les requêtes soient espacées les unes des autres
Et si tu as 1000 personnes de connectées sur ton site le serveur se prend 3000 connexions en 2 secondes ! et même si tu espaces tes requêtes
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.
$moi= ( !== ) ? : ;
Merci beaucoup pour ces réponses claires et précises
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 !
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager