Discussion :

[genova]

Optimise ton script ...

[vynarim]

L'optimisation n'est pas �vidente.

Peux t on grouper en mysql un envoi de requetes ?
En fait mon script fais 60 fois la meme �tape (calculs divers) pour � chaque fois faire un update d'une ligne d'une table (ligne diff�rente � chaque fois)

Peut etre serait il possible d'atttendre d'avoir toutes les requetes pour les envoyer en une fois � la base ?

[genova]

Tu peux faire un copie colle de ton script ici qu'on voye ce qu'il y a a optimiser ?

[Celelibi]

J'ai eut besoin il y a quelques jours de tester si la solution utilisant MySQL �tait plus rapide que la solution utilisant PHP.

Ma question �tait de tester si une ligne existait dans une table. Il ne pouvait y avoir au maximum qu'une seul ligne.
Donc vallait-il mieux s�lectionner la ligne et tester son existance avec mysql_num_rows(), ou alors utiliser la fonction COUNT() de MySQL, puis ensuite r�cup�rer un tableau avec mysql_fetch_array puis en extraite la valeur voulue ?

Pour r�pondre � cette question j'ai r�alis� un benchmark
R�sultat (pour ma machine) : une moyenne de 22 ms pour le mysql_num_rows contre 15ms pour COUNT.
(Pour ce test j'ai r�alis� 100000 it�rations allant de la requ�te jusqu'a la r�cup�ration concr�te du nombre de ligne.)


Maintenant �a peut parraitre un peu b�tat de dire que c'est plus rapide en utilisant les fonction de mysql, mais � l'origine cette question ne m'a pas parru �vidente.

Je pense donc que ceci est g�n�ralisable � la plus part des cas : pr�f�rer la solution MySQL lorsque vous avez le choix entre une solution MySQL et PHP.


J'en profite pour poser une petite question : vaut-il mieux stoquer dans une bdd les dates sous formes d'unix timestamp (dans un champ de type INT) ou un des formats de date de mysql ?

[genova]

Benchmark est ton ami dans ce cas

[Kioob]

J'en profite pour poser une petite question : vaut-il mieux stoquer dans une bdd les dates sous formes d'unix timestamp (dans un champ de type INT) ou un des formats de date de mysql ?

Si tu utilises le format DATE de MySQL, tu pourras faire un grand nombre de calcul directement via MySQL. Et si besoin, tu pourras quand m�me r�cup�rer le timestamp UNIX, via la fonction MySQL d�di�e � cela.

Par contre si tu stockes en timestamp, tu vas �tre fortement limit� question calculs, et un grand nombre de taches risque d'etre rel�gu� � PHP.

[winzou]

DATETIME plutot non ?
Sinon tu perd les infos heures/minutes/secondes

La doc mysql est ton amie aussi, tr�s int�ressante je trouve :
http://dev.mysql.com/doc/mysql/en/da...functions.html

Existe m�me en francais :]
http://dev.mysql.com/doc/mysql/fr/da...functions.html

[Blustuff]

Bonsoir,

Si je veux acc�der � n donn�es, uniques, mais acc�d�es � chaque execution d'un script, vaut il mieux cr�er une table mysql rien que pour stocker ces n donn�es, ou utiliser un fichier � la place ?

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
$Variables = file('variables');
...
$v_i = $Variables[i];
...
$Variables[m] = $v_m;
...
$Fichier = fopen('variables','a');
fwrite ($Fichier, join("\n", $Variables));
fclose($Fichier);

Ou un genre de sch�ma similaire ?

[genova]

Si tu utilises �norm�ment de SELECT de ton fichier (c'est � dire de lecture) et que tu utilises relativement peut d'�criture (UPDATE, INSERT) je te conseil de passer par un fichier, mais stoque ces fichiers sous forme de tableau PHP avec var_export().

Par exemple :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<?php
$ary = array(
   0 => array(
      'champ1' => 'valeur1',
      'champ2' => 'valeur2'
   ),
   1 => array(
      'champ1' => 'valeur1',
      'champ2' => 'valeur2'
   ),
   2 => array(
      'champ1' => 'valeur1',
      'champ2' => 'valeur2'
   ),
);
?>

Un simple include() et hop le tour est jou�.



A part �a j'ai effectu� un benchmark qui m'a largement surpris. J'ai fait une fonction de test qui recoit de trois facon un tableau de 1000 �l�ments. Il recoit ce tableau en param�tre lors du premier test, lors du second test en global, lors du troisi�me par r�f�rence.

Je fais une it�ration de 10000 tour avec appel de fonction, le r�sultat est sans appel :
passage du tableau en argument : 5.0572290420532 secondes
passage par globalisation : 0.026066064834595 secondes
Passage par r�f�rence : 0.024504899978638 secondes


Voici le code utilis� pour le passage en argument :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
<?php
include('function.php');
include('class_benchmark.php');
$ary = array();
for ($i = 0; $i < 1000; $i++)
{
   $ary[$i] = $i * $i;
}
function test($ary)
{
   $ary[0]++;
}
$bench = new bench();
for ($i = 0; $i < 10000; $i++)
{
   test($ary);
}
$bench->finish();
?>

J'en conclu qu'il faut fortement �viter de passer des grosses donn�es par argument � sa fonction (ce qui parait logiquie car toute la m�moirre alou�e pour cet �l�ment est pass�e � la fonction).

[Blustuff]

J'ai du mal m'exprimer. Je voulais dire n variables :

Variable 1
Variable 2
...
Variable n

qu'on peut coder en mysql comme une table avec deux champs "Nom Variable" et "Valeur" (ou en une seule ligne ^^ mais c'est pas beau)

[menkajunan]

Je fais une it�ration de 10000 tour avec appel de fonction, le r�sultat est sans appel :
passage du tableau en argument : 5.0572290420532 secondes
passage par globalisation : 0.026066064834595 secondes
Passage par r�f�rence : 0.024504899978638 secondes

effectivement, c assez impressionant ..

[titoon]

J'en conclu qu'il faut fortement �viter de passer des grosses donn�es par argument � sa fonction (ce qui parait logiquie car toute la m�moirre alou�e pour cet �l�ment est pass�e � la fonction).

??
C'est surtout parce que dans une fonction, PHP travaille sur des copies des variables pass�es en param�tre (donc si tu passes un bon gros tableau en param�tre, PHP va devoir le copier)

[ALkyD]

Salut,

j'ai une question qui me turlupine :

Dois-je syst�matiquement activer la compression GZip ? Je voudrais savoir si elle correspond � un type de sites particuliers, ou bien si elle est efficace dans tous les cas ?

Je suis en train de faire un projet � la SPIP, et je me demande simplement si je dois faire une constante GZIP pour activer ou non la compression HTTP...

Merci de votre aide.

[131]

Pourquoi alors ne pas travailler qu'avec des r�f�rence ?
Est-ce un reflexe � prendre ?

[jcachico]

salut,

- les calculs r�p�t�s dans les boucles du style

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

for($i=0;$i<sizeof($arr);$i++)

ca c'est pas bon!!!

peux-tu pr�ciser un peu, je capte pas l�...

A chaque tour dans la boucle tu calcule le

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

sizeof($arr)

alors en le sortant avant la boucle tu le calcule une fois pour toutes.
Au bout de la boucle tu aurra economis� du temps...

[titoon]

salut,

- les calculs r�p�t�s dans les boucles du style

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

for($i=0;$i<sizeof($arr);$i++)

ca c'est pas bon!!!

peux-tu pr�ciser un peu, je capte pas l�...

A chaque tour dans la boucle tu calcule le

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

sizeof($arr)

alors en le sortant avant la boucle tu le calcule une fois pour toutes.
Au bout de la boucle tu aurra economis� du temps...

Pour info, il existe en PHP une boucle tout sp�cialement pr�vue pour parcourir les tableaux... cf foreach
Et quelques notes en plus sur les diff�rentes boucles l�

[praentitong]

oui mais il arrive qu'on ne veuille pas les deux premi�res cases du tableau...dans ce cas un for est bien pratique.

[Blustuff]

Si j'ai deux tables A et B, et je veux selectionner des enregistrements de A, et quelques enregistrement de B associ�s. Du style

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

SELECT ... FROM A LEFT OUTER JOIN B ON A.Id = B.Id AND A.Cle = 'Constante'

Vaut il mieux faire r�element la jointure externe, ou vaut il mieux tout rappattrier par une jointure interne, et trier apr�s ce que je garde ou non dans chaque enregistrement ?

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

SELECT ... FROM A  JOIN B ON A.Id = B.Id

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
$Enregistrement = mysql_fetch_array();
 
if ($Enregistrement[Cle] == 'Constante')
  ...
else
  ...

[Squallynou]

Bonjour,


Interessant ce sujet. Je l'ai trouv� en cherchant justement quel �tait le plus rapide entre un while et un foreach.

J'ai beaucoup vu que vous parliez de lib�rer la m�moire du server, mais cel� se fait au d�triment du CPU non ?

Donc faut il vraiment d�truire les variables temporaires � chaque fois, et lib�rer les r�sult Mysql, ce qui lib�re de la m�moire mais utilise le CPU � chaque appel de fonction ?

J'apporte ma pierre � l'�difice. Enfin... Disons mon petit caillou plut�t, mais c'est l'intention qui compte ^^ :

Lorsque vous devez compter un nombre d'enregistrement d'une table compotant un champ 'id', et que cette table ne subit jamais d'effacement (table contenant chaque connection au site par exemple, pour faire un compteur avec stats sur le pays etc.) plut�t que de faire un Where 1 et compter le nombre de lignes retourn�es, faites un Where 1 order by id desc limit 0,1

L'id retourn� est le dernier et correspond au nombre d'enregistrement puisque dans ce genre de table aucun n'est supprim�. Donc un seul enregistrement retourn� au lieu de tous.

[Blustuff]

Il est tr�s difficile de faire les bons tests de rapidit�s. Beaucoup de tests sur internet montrent que pour charger le contenu d'un fichier la fonction file_get_content est la plus rapide. En pratique, fgets peut �tre de 20 % plus rapide � infiniement plus long suivant les param�tres. 20 % sur le chargement d'un gros fichier, ce n'est pas rien.

Il y a toujours un tas de param�tres que l'on oublie, et l'optimisation n'est pas simple. Le pire est qu'elle d�pend avant tout de la machine sur laquelle le script tourne. D'une machine � l'autre, d'une configuration � l'autre, les meilleures solutions ne seront pas toujours les m�mes.