Optimisation de scripts PHP/MySQL

Citation:

---

Envoy� par genova

Effectivement, si ton script fait 500Ko et que tu utilises toutes les lignes une " au lieu d'une ' tu gagneras peut �tre un milli�me de seconde en appliquant l'optimisation :D

Ce que je voulais dire c'est qu'il y a optimisations utiles, et optimisations inutiles. Un d�veloppeur qui connait parfaitement les optimisations microscopique de ce genre, mais qui n'est pas capable de cr�er un index corect sur sa base de donn�e, aura des scripts hyper lent ... Les plus grosses optimisations en PHP ca reste du c�t� des requ�tes SQL, et aussi de la mise en cache des calculs assez imposants dans le genre :

Code:

---

1 2 3 4 5

if (!$result = cache_get('resultat')) { $result = ... // Gros calcul cache_put('result', $result); }

---

L'utilisation de variables statiques peut aussi �tre un gain de temps, par exemple si on a une fonction smiley() :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

function smiley($str) { static $smilies = null;   if ($smilies === null) { // Récupération des smilies dans la database ou dans un répertoire }   foreach ($smilies AS $origine => $replace) { $str = str_replace($origine, $replace, $str); } return ($str); }

---

---

c'est vrai ca sert � rien non plus d'enc...u........r les mouches

:)

Bonjour !
Bonne id�e ce forum, quelqu�un sait si :

Code:

---

elseif { … }

---

et

Code:

---

else if { … }

---

Ont une diff�rence au niveau de la vitesse ?
Merci d�avance

Citation:

---

Envoy� par dorian53

Code:

---

SELECT pseudo FROM membres LIMIT 40,20

---

Solution optimis�e...

---

Heu excusez du peux mais si MySQL ne sais pas en interne optimiser une telle requ�te il est bon pour la poubelle

car tous les SGBD que j'ai rencontr�s parcourent l'index primaire de la table et limite l'index puis ensuite remonte les donn�es et ceci si la table � un volume important car dans le cas contraire il est plus couteux de'utiliser un index et le moteur de lui m�me choisit de parcourir la table il est impossible sur un moteur �volu� d'optimiser plus une telle requ�te.

l'explain de PostgreSQL est particuli�rement claire pour comprendre la strat�gie
cr�ez deux table une � forte poulation lautre non et lancez un explain de cette requete sur les deux

l'optimisation de la requ�te d�pends de l'usage statistique de la base et les moteurs adapte leur strat�gie au fil du temps.

l� ou vous allez pouvoir intervenir c'est sur l'optimisation de requ�tes imbriqu�es

Code:

---

1 2 3 4 5 6 7 8

SELECT referencetable.*, CASE mt_id WHEN '25' THEN 't' ELSE 'f' END AS selected FROM referencetable LEFT JOIN (SELECT * FROM selecteditems WHERE mt_id = '25') AS list USING (rt_id)

---

ou

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

(SELECT referencetable.*, 't' AS selected FROM referencetable INNER JOIN selecteditems USING (rt_id) WHERE mt_id = '25') UNION (SELECT referencetable.*, 'f' AS selected FROM referencetable LEFT JOIN selecteditems USING (rt_id) WHERE mt_id <> '25')

---

les deux remonte la table "referencetable" compl�te avec un champs selected � 't' ou 'f' suivant que la ligne est r�f�renc� dans selecteditems pour l'id 25

mais la deuxi�me fait deux jointure sur les deux taable � lors que la premi�re en fait qu'une. il y a bien deux select dans les deux
sur un bon moteur de base (orcle postgres Sqlserver ingre ...) les requ�tes suivantes sont paraitement �quivalente (l'explain done exactement la m�me strat�gie)

Code:

---

1 2 3 4

SELECT referencetable.* FROM referencetable INNER JOIN (SELECT * FROM selecteditems WHERE mt_id = '25') AS list USING (rt_id)

---

ou

Code:

---

1 2 3 4 5

SELECT referencetable.* FROM referencetable INNER JOIN selecteditems USING (rt_id) WHERE mt_id = '25'

---

ou

Code:

---

1 2 3 4 5

SELECT referencetable.* FROM referencetable, selecteditems WHERE mt_id = '25' AND referencetable.rt_id = selecteditems.rt_id

---

Et heureusement car un SGBD est avant tout un moteur de calcul ensembliste s'il ne le faisait pas cela signifirait qu'il ne fait du calcul d'ensemle mais du calcul procedural

tout SGBD � des limite et j'espere que MySQL fait pareil sion c'est grave.
d�j� qu'il ne sait pas faire un truc aussi simple que le B-A-BA des jointures multiples

Code:

---

1 2 3 4 5 6

SELECT * FROM table_principale INNER JOIN table_ref1 USING (tr1_id) INNER JOIN table_ref2 USING (tr2_id) INNER JOIN table_ref3 USING (tr3_id) INNER JOIN table_ref3 USING (tr4_id)

---

Ou la table principale contient les id tr1_id,tr2_id,tr3_id,tr4_id
MySQL ne sais pas ordoner ses jointures pour obtenir le r�sultat ce qui est une grave lacune.
dans un cas pareils il faut en passer par une forme en WHERE (qui en th�orie sont �quivalentes. visiblement pas pour MySQL) et c'est d�veloppeur d'optimiser l'ordres des jointures alors que cela peux d�pendre au fil du temps et de la charge des tables

A+JYT

Citation:

---

Envoy� par Sined_

Bonjour !
Bonne id�e ce forum, quelqu�un sait si :

Code:

---

elseif { … }

---

et

Code:

---

else if { … }

---

Ont une diff�rence au niveau de la vitesse ?
Merci d�avance

---

je pense que elseif est plus optimis�. D�j� il est pr�vus pour. Pour l'autre je pense que �a lui fait un embriquement de zone de condition et c'est le faite d'embriquer les bloques de condition qui prend plus de m�moire. Mais l'un ou l'autre le gain n'est pas vraiment quantifiable. Il faut plus coder avec bon sens que de chercher des � secondes qui ne servent � rien. :king:

J'en doute ... le parseur PHP interpr�te tr�s probablement else if et elseif comme un seul et m�me token.

Citation:

---

Envoy� par genova

J'en doute ... le parseur PHP interpr�te tr�s probablement else if et elseif comme un seul et m�me token.

---

exatement
je pense m�me que le compilateur (car il y en) a un doit produire le m�me code que pour

Code:

---

1 2 3 4 5

if () { } else { if () { } }

---

Je n'en mettrais pa sma main � coup� il y a tent de truc bizare dans le compilo zend
mais en g�n�ral les compilateur produise le m�me code pour les trois syntaxe
et � me parait normal
A+JYT

Test #1

Code:

---

1 2 3

for ($i = 0; $i < 4000000; $i++) { echo 'TEXT'; }

---

Test #2

Code:

---

1 2 3 4 5

$echo = ''; for ($i = 0; $i < 4000000; $i++) { $echo .= 'TEXT'; } echo $echo;

---

R�sultats
Le test #2 est g�n�r� trois � quatre fois plus rapidement !

Ainsi, il est plus judicieux de mettre en place un syst�me de cache d'affichage, plut�t que de multiplier les "echo". A cet effet, PHP met � notre disposition :

ob_start();
ob_end_flush();

Ainsi, le code ci-dessous sera (plus ou moins) �quivalent et tout aussi rapide que notre test #2.

Code:

---

1 2 3 4 5

ob_start(); for ($i = 0; $i < 4000000; $i++) { echo 'TEST'; } ob_end_flush();

---

Citation:

---

Envoy� par Metallic-84s

Test #1

Code:

---

1 2 3

for ($i = 0; $i < 4000000; $i++) { echo 'TEXT'; }

---

Test #2

Code:

---

1 2 3 4 5

$echo = ''; for ($i = 0; $i < 4000000; $i++) { $echo .= 'TEXT'; } echo $echo;

---

R�sultats
Le test #2 est g�n�r� trois � quatre fois plus rapidement !

Ainsi, il est plus judicieux de mettre en place un syst�me de cache d'affichage, plut�t que de multiplier les "echo". A cet effet, PHP met � notre disposition :

ob_start();
ob_end_flush();

Ainsi, le code ci-dessous sera (plus ou moins) �quivalent et tout aussi rapide que notre test #2.

Code:

---

1 2 3 4 5

ob_start(); for ($i = 0; $i < 4000000; $i++) { echo 'TEST'; } ob_end_flush();

---

---

En faite, ce que tu avances � des limites. En effet �a depend de ce que la variable mange comme texte � chaque boucle. Car plus la boucle avance plus cela va ralentire le systeme. J'ai constat� ce ph�nom�ne en php ainsi qu'en C#. A chaque fois qu'il y a une boucle il est oblig� de ranger les informations dans la variable donc la m�moire.

C'est toujours le m�me compromis : augmenter la mise en cache am�liore les performances mais augmente la consommation de m�moire (et complique souvent le code). Je pense que ce n'est pas � ce niveau qu'il faut chercher l'optimisation, d'ailleurs il ne faut pas chercher l'optimisation mais le code lisible (donc p�renne).

Apprenez � utiliser un framework : cela fera baisser les perfs de votre site mais au moins vous vous y retrouverez d'une ann�e sur l'autre, sans devoir vous gratter la t�te en relisant votre ancien code (j'en vois qui se reconnaissent) :mouarf:


Je pr�ne les perfs en qualit� plut�t qu'en temps d'ex�cution. De toute mani�re, les serveurs sont g�n�ralement surdimesionn�s et c'est habituellement la base de donn�es qui ralentit l'application, pas les boucles en PHP.

Citation:

---

Envoy� par Yogui

C'est toujours le m�me compromis : augmenter la mise en cache am�liore les performances mais augmente la consommation de m�moire ....
Je pr�ne les perfs en qualit� plut�t qu'en temps d'ex�cution. De toute mani�re, les serveurs sont g�n�ralement surdimesionn�s et c'est habituellement la base de donn�es qui ralentit l'application, pas les boucles en PHP.

---

Je suis bien d'accord avec la premi�re partie
mais pas du tout avec la deuxi�me.
bien trop souvent on vois �crit en php ce que la base sait faire avec des perf tr�s largement supp�rieures.

personnellement je n'ai jamais eu de ralentissement due � ma base. et pourtant il m'arrive dans une seule requ�te de brasser pluseirus dixaine de table de plusieur millons d'enregistrement pour certaines.
les temps de r�ponse sont bien inf�rieur � la m�me chose fait en php avec de multiples acc�s.

alors mieux vait solliciter la base correctement que de faire des boucles php
j'ai un exemple d'une requ�te qui remonte toujours exactement 25 lignes de 4 collones mais pour y arriver elle brasse 15 tables avec des calculs et intersection de plages horaires sur des milliers d'enregistrement.
ma boucle fait 24 it�ration et la base r�ponds en quelques secondes. si je devais solliciter la base et faire toutes les boucles pour croiser mes donn�es et faire mes calcul en php je passerais � coup sur les time out.

�crire une bonne structure de base et des requ�te coh�rentes est un gage de perf. bien plus que toutes les boucles optimis� imaginable en php.

A+JYT

Si tu relis ce que j'ai �crit, nous somems parfaitement d'accord : coder correctement est un meilleur gage de performances que chercher la petite b�te. En plus, �a fait du code plus facile � maintenir.

A prioris �a n'a pas �t� post�

Plutot que de faire :

Code:

---

1 2 3 4 5 6 7 8

$req = mysql_query("SELECT COUNT(*) as nb FROM `table` WHERE `id`=".$id); $rslt = mysql_fetch_array($req);   if($rslt['nb'] > 0){ mysql_query("UPDATE `table` SET `time`=".time()." WHERE `id`=".$id); }else{ mysql_query("INSERT INTO `table` (`id`, `time`) VALUES ('$id', '".time()."')"); }

---

Faire :

Code:

---

mysql_query("INSERT INTO `table` (`id`, `time`) VALUES ('$id', '".time()."') ON DUPLICATE KEY UPDATE `time`='".time()."');

---

Bien sur cela implique d'avoir mis le champ `id` en cl� primaire

Pour info, MySQL propose la clause REPLACE INTO, dont la syntaxe est identique � l'INSERT INTO ;)

Manuel Mysql

Citation:

---

REPLACE works exactly like INSERT, except that if an old row in the table has the same value as a new row for a PRIMARY KEY or a UNIQUE index, the old row is deleted before the new row is inserted. See Section 13.2.4, �INSERT Syntax�.

---

Donc dans les tables InnoDB avec suppression en cascade on se retrouve � supprimer tous les contenus des autres table du meme ID.
Alors que le ON DUPLICATE KEY fait un UPDATE

Le ON DUPLICATE KEY marche � partir de quelle version de MySQL ? Marche postGreSQL et SQLite ?

A partir de MySQL 4.1.

Et je pense que c'est sp�cifique � MySQL

http://www.estvideo.com/dew/index/20...ate-key-update

Ca marche seuleument avec les tables InnoDB me semble-t-il...

Pour revenir sur le LIMIT et le BETWEEN:

Pour ma part je ne vois pas le m�me r�sultat entre les 2 requ�tes.
L'une est execut�e par rapport "aux lignes de la table", l'autre par rapport � l'id.
Me tromperai-je ????

Citation:

---

Envoy� par Kioo

Ca marche seuleument avec les tables InnoDB me semble-t-il...

Pour revenir sur le LIMIT et le BETWEEN:

Pour ma part je ne vois pas le m�me r�sultat entre les 2 requ�tes.
L'une est execut�e par rapport "aux lignes de la table", l'autre par rapport � l'id.
Me tromperai-je ????

---

Oui et non. En faite le between n'a pas de rapport sur leur but. L'un te donne un certain nombre de r�sultat par rapport � un point de d�part. Les valeurs n'ont pas besoin d'�tre connu. Le Between retourne un jeux de resultat suivant un altervale entre deux num�rique ou date. Donc la valeur � besoin d'�tre connu.
Mais pour des raisons de performance les deux peuvent servir pour �muler un limit beaucoup moin gourmant. Imaginez que tu dois faire un limit sur une table ayant plus de 100 000 enregistrements. Le LIMIT va ramer si tu lui demande 10 par 10 arriv� dans le 90 000eme enregistrement.
Le truc c'est de faire un limite uniquement sur une cl� unique. A partir de ce jeux de resultat tu prend la premiere et la derniere et tu le place dans le Between. Mais maintenant nous nous rendons compte que vu que nous avons les 10 id nous pouvons tous simplement utiliser un IN(...)
Cette astuce est utilis� sur les gros forum fran�ais.

berceker united tu pourrais d�velopper un peu plus l'optimisation du LIMIT + BETWEEN ? Ca m'interesse beaucoup, mais j'ai pas saisi dans l'int�gralit� le raisonement.

Sinon � la question LIMIT = BETWEEN ? Bien sur que non. LIMIT est appliqu� sur le r�sultat, alors que BETWEEN est un filtre et sert donc � calculer le r�sultat.

Le probl�me de BETWEEN, c'est que si par exemple tu as supprim� des entr�es, et que tu as des "trous" dans tes ID, il te renverra moins de r�sultats que pr�vu, alors que LIMIT renverra les X r�sultats que tu demandes.

Citation:

---

Envoy� par genova

berceker united tu pourrais d�velopper un peu plus l'optimisation du LIMIT + BETWEEN ? Ca m'interesse beaucoup, mais j'ai pas saisi dans l'int�gralit� le raisonement.

Sinon � la question LIMIT = BETWEEN ? Bien sur que non. LIMIT est appliqu� sur le r�sultat, alors que BETWEEN est un filtre et sert donc � calculer le r�sultat.

Le probl�me de BETWEEN, c'est que si par exemple tu as supprim� des entr�es, et que tu as des "trous" dans tes ID, il te renverra moins de r�sultats que pr�vu, alors que LIMIT renverra les X r�sultats que tu demandes.

---

Lorsqu'il y a une requ�te pouvant retourner plusieurs champs dont les tables poss�de �norm�ment d'enregistrements, l'utilisation d'un LIMIT peut �tre catastrophique point de vue performance. Plus le curseur de d�part du LIMIT s'�loigne du d�but des enregistrements plus les performances se d�grade.
Dans ce genre d'op�ration il faut faire l'op�ration en deux temps.
Premier temps faire une requ�te r�cup�rant que l'id avec le LIMIT.

Code:

---

SELECT id FROM forum LIMIT 65412, 10;

---

Resultat:
id de 125455 ... 125465

Second temps, avec le jeux de resultat avec juste les id vous faite ceci.

Code:

---

SELECT * FROM forum id BETWEEN 125455 AND 125465

---

ou

Code:

---

SELECT * FROM forum id IN(125455,125456,125457,...,125465)

---

Pas de probl�me de trou parce celui sera automatiquement combl� vie le LIMIT qui lui va toujours retourner le m�me nombre de r�sultat sauf � la fin.