Optimisation de scripts PHP/MySQL [Débat]

**Yogui** · 16/06/2008, 12h17

Eh bien si, justement, si tu n'utilises pas pconnect, les connexions se ferment automatiquement à la fin du script

**libuma** · 16/06/2008, 15h11

Vous me rendez fous !! lol

okok merci beaucoup

**Delapouite** · 16/06/2008, 15h53

Je suis plutôt de l'avis de fermer la connexion à la base de données dès la dernière requête effectuée, autrement dit dès qu'on en a terminé avec la couche Models de l'application.

Ca ne sert à rien, et peut même devenir nuisible de la laisser ouverte pendant le traitement des données puis la génération de la vue, qui si elle est conséquente, peut durer de 1 à plusieurs secondes.

**berceker united** · 16/06/2008, 15h56

Envoyé par gseverin

C'est sur si tu as un site qui accueillle 1 personne par jour la inutile de dimensionner .

Au contraire si ton site a un certain succés , il est préférable de fermer les connexions.

Une personne qui consulte ton site et qui ne referme pas son navigateur maintien la connexion.

sans compter celles qui surfent , on peut arriver vite au nombre de connexions autorisées PAR UTILISATEUR ; 48 pour infomaniak Une vingtaine POUR OVH , il ne faut pas être très fute fute pour le comprendre , tout ça bien sur si le site a pas mal de visites.

D'ailleurs OVH propose de redimensionner ce nombre à la hausse moyennant finance , tiens curieux !! n'est-ce pas !!!!

De toutes les façons , dans les FAQ il est conseillé cette façon de faire.

Pour info , pour ne pas te prendre la tête , tu fais un include d'une page en entete de ton script ou la tu as ton connect de ta base.

et en bas de ta pas tu fais un close de ta connexion avec un include .

tu inclus ces scripts a chaque fois que tu commences un script et la en effet tu te poses pas de question.....

Faux. La connexion se ferme à la fin du parsage du script PHP. Il y a pas de liaison permanente entre le navigateur et le serveur. Ce dernier envois ça page au navigateur et il ne le connait plus du tout. Heureusement que c'est ainsi parce qu'il faudrait des bases de données ayant la possibilité d'ouvrir des milliers de connexion en même temps.

**Yogui** · 16/06/2008, 16h16

Envoyé par Delapouite

Ca ne sert à rien, et peut même devenir nuisible de la laisser ouverte pendant le traitement des données puis la génération de la vue, qui si elle est conséquente, peut durer de 1 à plusieurs secondes.

C'est bien ce que je disais plus haut : Si tu as de tels temps de réponse, alors l'optimisation du nombre de requêtes ouvertes est bien le dernier de tes soucis... Si ta vue met effectivement plus d'une seconde à s'afficher, alors il faut que tu te renseignes de toute urgence sur les techniques de mise en cache, mais tu peux tout de suite laisser tomber les sujets aussi triviaux que ce dont il est question ici

**libuma** · 16/06/2008, 21h12

Et bien tant que j'y suis , je vais vous introduire une nouvelle question qui me trotte si vous voulez bien..
J'en profite vu qu'en même temps nous sommes dans un sujet qui traite l'optimisation ^^

Alors voila , j'ai fais un site (de vente mais peu importe) où en faite je n'ai qu'une page "officielle" , c'est l'index.php..
j'utilise des modules donc , ce qui me donne quelque chose comme :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
<head>
..
</head>
<body>
header();
if(isset($_GET['section']) && in_array($_GET['section'], $sections))
  include('mod/' . $_GET['section'] . '.inc.php');
else
  code de la page d'accueil
footer();
</body>

Et dans mes modules , j'ai parfois d'autres modules, des genres de sous modules en quelques sortes..

Est-ce là un bon procédé?

J'ai noté pas mal d'avantages , notamment dans la lisibilité et la structure, et par exemple un avantage : je ne dispose que d'une balise body , donc que d'une seul possibilité de "onload" pour le JS.

J'aimerais avoir votre avis.. merci !

**Yogui** · 16/06/2008, 21h52

@libuma : Oui, c'est ce que l'on appelle un script de bootstrap, c'est une technique utilisée par tous les frameworks modernes.

Les noms de fichiers viennent en effet d'une variable client $_GET['section'], mais tu supprimes le risque en utilisant une "liste blanche" avec un tableau local $sections. Ta méthode est donc correcte et sécurisée

**Alekusu** · 03/07/2008, 03h02

Dans le cas d'un magazine en ligne, où on aurait par exemple une quinzaine de requete SQL SELECT pour afficher différents éléments sur la home, ne serait-ce pas plus malin de :

1/ Créer une table pour la home, où dynamiquement à chaque modification coté back office, ça update cette table qui contient uniquement les éléments à afficher sur la home

2/ Appeler avec une seule requete SQL SELECT tout le contenu de cette table et afficher son contenu au fur et à mesure de la page.

J'ai jamais lu ce genre de proposition qui en plus de faire des tables par type de données fait aussi des tables par page.

Vous pensez que dans le cas de sql select c'est une solution pertinente ?

**savageman86** · 03/07/2008, 08h39

Bah si tu construits ta page avec 15 requêtes SQL ça commence à faire. Plutôt que de créer un autre table sous prétexte que c'est la page d'accueil et donc qu'elle est appelée plus souvent, il faut plutôt la mettre en cache. Si ta page est affichée 1 fois par seconde et que tu mets un cache d'une minute, les 15 requêtes ne seront exécutées que 1 fois sur 60, ce qui est largement acceptable.

En plus c'est super facile à faire !

**Alekusu** · 03/07/2008, 19h24

Tout dépend de quel type de mise en cache tu parles. Si c'est avec un système de template, c'est lourd à mettre en place. Tu parles de quel type de mise en cache ?

**Sékiltoyai** · 19/08/2008, 13h39

Quelqu'un aurait-il récemment fait un bench foreach() vs array_map() vs array_map+create_function() ?
Il me semble que les lenteurs de array_map() ont été fixées, non ?

**keusty78** · 14/03/2011, 19h32

j'ai aussi vus et entendu qu'il etait preferable d'utilisé directement les variable
exemple :

exemple:1

Code :

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

echo $_POST['champ'];

mieu que :

exemple2

Code :

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

1
2
3
 
$champ=$_POST['champ'];
echo $cahmp;

;

a confirmé car je ne sait pas dutout si il y a une grosse diference

**stealth35** · 14/03/2011, 20h18

Envoyé par keusty78

j'ai aussi vus et entendu qu'il etait preferable d'utilisé directement les variable
exemple :

exemple:1

Code :

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

echo $_POST['champ'];

mieu que :

exemple2

Code :

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

1
2
3
 
$champ=$_POST['champ'];
echo $cahmp;

;

a confirmé car je ne sait pas dutout si il y a une grosse diference

ca depend de ca que tu veux faire, en tout inséré une valeur brute de POST est une faille (plus ou moins grave suivant les requêtes)

et si tu veux afficher une valeur de POST dans le html il faut aussi faire un htmlspecialchars

**keusty78** · 14/03/2011, 21h55

oui c'est vrais stealth35 mai peut on pas proteger une variable directement meme si elle n'es pas defini? par exemple :

mysql_real_escap_string($_POST['champ']);

je dis sa comme sa mai en meme temp vous etes plus experimenter que moi dans le domaine

**stealth35** · 14/03/2011, 21h58

Envoyé par keusty78

oui c'est vrais stealth35 mai peut on pas proteger une variable directement meme si elle n'es pas defini? par exemple :

mysql_real_escap_string($_POST['champ']);

je dis sa comme sa mai en meme temp vous etes plus experimenter que moi dans le domaine

si $_POST['champ'] n'existe pas oui tu vas avoir une erreur,
mais je te conseil d'oublier le mysql_real_escap_string, et de vite passé sous mysqli ou PDO_MySQL

**Seb33300** · 15/03/2011, 01h51

mysql_real_escape_string() c'est pour protéger une chaîne de caractère qui va être utilisée dans une requête SQL via mysql_query() d'une injection SQL.

Passer à mysqli ou à PDO ne résoudra pas le problème. Il y a des fonctions équivalentes à utiliser.
Sinon il faut passer par des requêtes préparée, ce que les fonction mysql_ ne permettent pas.

htmlentities() / htmlspecialchars() permettent de protéger le code HTML qui sera envoyé au navigateur. (failles XSS, etc..)

Apres, le fait de passer par une variable intermédiaire plutôt que d'utiliser $_POST directement ne sert pas à grand chose à part consommer un peu plus de mémoire inutilement.

**stealth35** · 15/03/2011, 10h25

Envoyé par Seb33300

Passer à mysqli ou à PDO ne résoudra pas le problème. Il y a des fonctions équivalentes à utiliser.
Sinon il faut passer par des requêtes préparée, ce que les fonction mysql_ ne permettent pas.

jamais dis l'inverse, regarde le lien (surtout le tableau du bas).

**sekaijin** · 15/03/2011, 10h49

Envoyé par keusty78

...

Code :

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

1
2
$champ=$_POST['champ'];
echo $cahmp;

;...

ne faite JAMAIS ça
Une des options de PHP pour faciliter la vie du développeur était de justement le faire de façon automatique.

il existe donc des Hack pour tenter de corrompre les scripts.

Donc si vous affectez un champs d'un POST à une variable
évitez que cette variable ait pour nom la clef du champ

Code :

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

1
2
$n_importe_quoi_d_autre_que_champ=$_POST['champ'];
echo $n_importe_quoi_d_autre_que_champ;

;...[/QUOTE]
A+JYT

**nomad2** · 26/04/2011, 14h14

bonjour: svp mon français est trop faible mais j'essaye de m'exprimer pour mieux poser ma question .
dans un forum ou chat on trouve généralement une zone de texte je veux copier coller
dans cette zone une application visual basic et dans cette application un bouton si on clic sur ce bouton un texte apparait. b1 sur ce texte est préalablement programmer dans l'application par l'utilisateur de application et pas par l'utilisateur du chat ou du forum ,j'espère que c'est clair merci de votre compréhension .

**tse_jc** · 30/07/2012, 01h43

Bonjour,

Envoyé par alekusu

Dans le cas d'un magazine en ligne, où on aurait par exemple une quinzaine de requete SQL SELECT pour afficher différents éléments sur la home, ne serait-ce pas plus malin de :

1/ Créer une table pour la home, où dynamiquement à chaque modification coté back office, ça update cette table qui contient uniquement les éléments à afficher sur la home

2/ Appeler avec une seule requete SQL SELECT tout le contenu de cette table et afficher son contenu au fur et à mesure de la page.

J'ai jamais lu ce genre de proposition qui en plus de faire des tables par type de données fait aussi des tables par page.

Vous pensez que dans le cas de sql select c'est une solution pertinente ?

Cette approche bien qu'elle soit juste dans l'intention n'est pas bonne du tout dans la forme, car c'est ainsi que fonctionnent la plupart des CMS et qui dans le cas présent constiste à utiliser la BD pour faire de la persistance de classe ce qui est à proscrire dans un contexte où les performances et la disponibilité en charge doivent être garantis.

Dans le cas d'un site ecommerce il faut que la BD soit fortement normalisée et par conséquent qu'elle intègre les spécificités métier et fonctionnelles de l'applicatif Web.

Pour ce qui est de l'affichage, appliquer votre vision est la bonne méthode à ceci près qu'il faille le faire avec des vues, bien qu'avec MySQL des requêtes dédiées soient le plus souvent les plus appropriées.

++

Optimisation de scripts PHP/MySQL [Débat]

PHP & Base de données

Discussions similaires

Partager

Partager