Discussion :

[DgG]

Salut ! J'ai été confronté avec un site qui était hebergé sur un serveur dédier à la lenteur d'execution des page en Php.
En étudiant les documentation Php MySQL nous avons réussit a accelerer considerablement la vietesse et augmenter le nombre d'internaute sconnectés en même temps sur le site.
Donc voila, je vous propose que l'on se disent des techniques pour accelerer Php.

Je commence : 8)
- Simplifier au maximum les boucle while(...).
- Utiliser le moin de variables possible, en effet tout les variables son stocké dans la ram (nan ?).
- Réduire au maximum le nombre d'acces à une base de donnée (c'est important ça)
Par exemple lorsque que vous avez une adition à faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
au lieu de faire
$q=mysql_query("SELECT nombre FROM table WHERE condition");
$r=mysql_fetch_array($q);
$nombre=$r["nombre"] + $valeur;
msql_query("UPDATE table SET nombre = $nombre WHERE condition");
 
On ecrit cela :
mysql_query("UPDATE table SET nombre = nombre + $valeur WHERE condition");
Et oui ça mache ça !!
-Optimiser la structure de vos table MySQL(voir doc)

Enfin, regardez dans les documentations si il ny a pas une fonction Php ou MySQL qui remplaceraies votre script de bourin. De cette sorte, vous ne ferez plus soufrir votre serveur.

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

[stephane eyskens]

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

[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.

[hachesse]

Eviter toute opération unitile du type operation en 2 temps
$c = $a + $b;
$e = $c + d;
est plus lent que $e = $a + $b + $d;

D'une maniere générale, les optimisation possible pour une base de données sont ici : http://sqlpro.developpez.com/OptimSQL/SQL_optim.html

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

Utiliser des constantes plutot que des variables qui ne change pas (ex les login, mot de passe, host et nom de la base de données

Preferer la syntaxe simple pour les chaines de caratere (guillemets simples) qui ne sont pas analysées par l'interpreteur PHP contrairement a la syntaxe complexe (guillemets double ou syntaxe here doc)

Il y a aussi possibilité de mettre en cache les scripts PHP (ex php accelerator)

Il faut aussi penser a bien configurer le serveur que ce soit au niveau du materiel, du systeme d'exploitation ou du serveur http

[libuma]

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

Bonjour,
J'ai fais un site php où tous mes liens renvoient vers la page index.php mais avec des contenus(includes) différents..
Pour l'instant , dès que j'ai besoin de ma BD , j'ouvre la connect , j'envoie la requete puis je ferme..
Serais-ce plus optimal d'ouvrir la connexion au démarrage de la SESSION et de fermer la connexion à la BD lors de la fermeture de session?

Je n'ai pas , au premier jet , employé cette technique , car je me suis dis que l'utilisateur risquerait de garder la connex à la BD assez longtemps , je ne sais pas si c'est problématique ou non..

Merci de votre aide

[Yogui]

Salut

Tu es en train de proposer exactement le contraire de ce que recommande hachesse. Tu voudrais ouvrir une connexion permanente, mais de nombreuses discussions à ce sujet déconseillent cette approche.

[libuma]

Salut

Tu es en train de proposer exactement le contraire de ce que recommande hachesse. Tu voudrais ouvrir une connexion permanente, mais de nombreuses discussions à ce sujet déconseillent cette approche.

C'est le pourquoi du comment je n'ai pas fais celà..
Je reformule ma question alors :
Est-ce mieux d'ouvrir et fermer la connexion à chaque page ? (genre debut du body = connex , fin du body = deco)
ou alors l'ouvrir et fermer uniquement lorsque j'en ai besoin ? (ce qui signifie que parfois je ne l'ouvrirai pas , parfois je l'ouvrirai/fermerai plusieurs fois par page)

[Yogui]

Le mieux est d'utiliser des connexions éphémères, car les connexions peristantes subissent le gros problème d'Internet : on n'a aucun moyen fiable de déterminer quand l'utilisateur est inactif, absent, etc. Donc pas de connex persistantes, mais apparemment tu le sais déjà.

Restent les connexions éphémères.
Le plus simple est de ne jamais fermer manuellement la connexion : PHP s'en chargera lui-même en terminant l'exécution du script. Évidemment, réouvrir une connexion fermée dans un même script est une énorme perte de ressources.

[Invité(e)]

Bonjour,
J'ai fais un site php où tous mes liens renvoient vers la page index.php mais avec des contenus(includes) différents..
Pour l'instant , dès que j'ai besoin de ma BD , j'ouvre la connect , j'envoie la requete puis je ferme..
Serais-ce plus optimal d'ouvrir la connexion au démarrage de la SESSION et de fermer la connexion à la BD lors de la fermeture de session?

Je n'ai pas , au premier jet , employé cette technique , car je me suis dis que l'utilisateur risquerait de garder la connexion à la BD assez longtemps , je ne sais pas si c'est problématique ou non..

Merci de votre aide

En fait la plus part des providers ou hébergeurs si tu préféres , mettent à disposition des bases mysql avec un certain nombre de connexion simuatanées.

48 : pour INFOMANIAK ( exemple ) .

si tu conserves les connexions tu risques d'avoir un message du type server busy !!

Généralement on ouvre la connexion , puis un éxécute la requête puis un fois que l'on a son résultat on fait un close sur la connexion .

a+

[libuma]

une chose est sure , on évite les connexions persistantes alors ^^
pour le reste , vous m'avez donné deux versions différentes

Mais bon , merci de votre aide

[Yogui]

Fermer manuellement la connexion au plus tôt s'appelle de l'optimisation prématurée : La plupart du temps, les hébergeurs dimensionnent le nombre de connexions simultanées de manière à satisfaire tout le monde, tu n'as donc pas besoin de couper manuellement la connexion dans tes scripts de manière à gagner quelques pouillèmes de microseconde...

Si tu atteins le seuil de connexions simultanées, ce n'est pas en coupant dès que possible la connexion que tu résoudras le problème, mais en optimisant les requêtes elles-mêmes : ne pas faire un SELECT * si tu veux simplement compter le nombre de lignes, etc.


Bref, dans aucun cas il ne me semble utile de fermer manuellement la connexion à la base. L'avantage de cette pratique est que cela te permet de relancer une requête à tout moment sans te poser de question.

[King Bradley]

Bonjour tout le monde,

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

1) hachesse a dit ceci :

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 :

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];
}

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

[papajoker]

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

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 le serveur se prend 3000 connexions en 2 secondes ! et même si tu espaces tes requêtes

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.

[King Bradley]

Merci beaucoup pour ces réponses claires et précises

[ABCIWEB]

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.

[King Bradley]

Oui, je vois ça ^^

Merci à vous trois pour ces réponses !

[sekaijin]

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 :

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];
}

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