Optimisation de scripts PHP/MySQL

Version imprimable

Voir 40 message(s) de cette discussion en une page

10/08/2005, 05h06
Squallynou

Bonjour,

Un autre petit test sur l'affichage de chaines de caract�re avec variable et caract�res sp�ciaux.
Ex�cut� 30 000 fois chacun :

Citation:

m�tode 1 : <?php echo "une chaine de caract�re avec $var dedans et caract�re sp�ciaux : \n\n" ; ?>
dur�e : 0.20288

m�tode 2 : <?php echo 'une chaine de caract�re avec '.$var.' dedans et caract�re sp�ciaux : '."\n\n" ; ?>
dur�e : 0.076507

m�tode 3 : <?php echo 'une chaine de caract�re avec ', $var, ' dedans et caract�re sp�ciaux : ', "\n\n" ; ?>
dur�e : 0.062021

L'echo avec virgules est donc pr�f�rable quelque soit les param�tres.

Ce petit script permet de bencher un site. Il est conseill� de commencer par des petites it�rations afin de ne pas boucler pendant des heures ^^

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
 
    // Inclusion des lib PEAR 
    // --------------------- 
    // récupération de l'os sur lequel on est
    // on en a besoin pour déterminer le séparateur utilisé dans le PATH
    if (strstr(PHP_OS, 'WIN') == FALSE) 
    {
    	$separateur = ':';
    } 
    else 
    { 
    	$separateur = ';';
    }
 
    // Inclusion des lib PEAR
    // ---------------------
    set_include_path(get_include_path() . $separateur . 'PEAR');
 
    // Le client pour les requêtes
    // ---------------------------
    require_once 'HTTP/Client.php'; 
 
    // Bench du site (classe PEAR)
    // ---------------------------
    require_once ('Timer.php');               
 
 
    // les liens normaux
    $tab_link = array ('http://localhost/localweb/test/index.php?page=news',
                       'http://localhost/localweb/test/index.php?page=tools',
                       'http://localhost/localweb/test/index.php?page=dossierindex',
                       'http://localhost/localweb/test/index.php?page=membres,
                       'http://localhost/localweb/test/index.php?page=autre);
 
 
    // Positionner le runtime assez haut pour ne pas être bloqué
    set_time_limit(0);    // six minute timeout
    ini_set("memory_limit","256M");
 
    // Début du bench
    // --------------
    $bench = new Benchmark_Timer(); 
    $bench->start();
 
    $client =& new HTTP_Client(); 
 
    $bench->start();
 
    $cpt=0;
    // Bench de chaque page
    foreach ($tab_link as $a_row )
    {
        $cpt++;
        $bench->setMarker('test:'.$cpt);
         for ($i=0;$i<10;$i++)
        {
            $res = $client->get ( $a_row );        
        }
        $bench->setMarker('test de ' . $a_row );
    }
 
    $bench->stop();        
    $bench->display();

Il est possible d'en faire une fonction ou une classe, de rendre le nombre d'it�rations param�trables et de passer le tableau des liens a bencher en param�tre.
Ca permet de voir quelles sont les parties du site qui prennent le plus de temps et de garder des traces de ces perfs pour pouvoir les comparer plus tard apr�s une modification par exemple.

12/08/2005, 17h19
Tchinkatchuk

Citation:

Envoy� par Squallynou

Bonjour,

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.

un select max serait peut etre plsu conseille, non ?
12/08/2005, 17h21
poof65

un

Code:

select count(*) from table

c'est encore plus efficace (sur les tables myisam en tous cas)
12/08/2005, 17h30
Tchinkatchuk

oui, en cas d'un id manquant en plein milieu, c'est meme plus correct sinon c la meme chose voire moins en ressources mais je pinaille lol
12/08/2005, 19h32
thibob

et SELECT MAX(id) FROM table ? �a va pas?
12/08/2005, 22h46
Taum

Salut,
Il me semble avoir lu que MyISAM stocke le nombre d'enregistrement, dans tout les cas pour obtenir le nombre d'enregistrements, "SELECT COUNT(*) FROM table" devrait �tre la solution la plus rapide.
20/08/2005, 16h16
Blustuff

Petite remarque amusante. La fonction array_map est lente. Il est plus rapide d'utiliser un parcours avec foreach, que d'appliquer map. Apparement, il est �galement plus rapide de donner un nom de fonction en param�tre plut�t qu'une fonction lamda cr�e avec create_function. A v�rifier ;) J'ai gagn� 40 % rien qu'en rempla�ant les fonctions map. Interessant pour une partie dont le temps d'execution se compte en secondes.
25/08/2005, 15h05
shadeoner

redimenssionement image

Je souhaite afficher des images sur une page.
Les images p�sent environs 100ko chacune, je souhaite en afficher environs 30 par page.
Si j'utilise le la librairie GD2 pour redimenssioner, est ce que les images seront r�duites cot� serveur en �tant mise dans le cache (qui, normalement r�duirait le poid des images), ou alors c'est un redimenssionement cot� client (style <IMG width="xx" height="xx">) ??

Merci :)
30/08/2005, 02h40
bollob

Bonjour,

j'ai une table auteurs avec des attributs comme le nom, le pr�nom, le sexe...
Chaque auteur est li� � plusieurs articles dans une table articles (1 article = 1 enregistrement).
je veux ressortir tous les articles d'un auteur donn� ainsi que son nom, son pr�nom...

Du point de vue de l'optimisation vaut-il mieux faire deux requ�tes (et occuper du temps processeur) ou bien faire une jointure, quitte � avoir dans la table du r�sultat les attributs de l'auteur r�p�t�s pour chaque article (et donc occuper de la m�moire) ?

Sachant que pour l'exemple j'ai simplifi� � l'extr�me et que c'est beaucoup plus lourd en r�alit� (4 tables, entre 5 et 10 colones pour chaque table et jusqu'� plus d'une centaine d'enregistrements � ressortir).

j'�sp�re �tre clair (il est tard)

Merci d'avance.
01/09/2005, 09h07
genova

Pour ce type de configuration il faut faire une jointure, c'est justement fait pour �a ;)
06/09/2005, 14h28
Thanaroth

Je pense qu'on devrait refaire ce sujet... l� on a un paquet de posts, donc certains inutiles... j'ai pas eu le courage de tout lire...

je vais donc peut �tre redire des choses d�ja indiqu�es, mais voila mes habitudes en mati�re d'optimisation

Citation:

Portabilit�
- toujours utiliser la balise <?php au lieu du simple <?
- inclure des conditions pour d�tecter si certaines fonctions (tels que les magic_quotes) sont actives, et faire un addslashes ou non en cons�quence

�conomie de ressources
- bannir le "SELECT *" de ses scripts... m�me si on prend la totalit� des champs, les nommer un par un, ce qui permet de s'y retrouver plus facilement par la suite, mais surtout d'�conomiser les ressources dans le cas o� un nouveau champ (et inutilis� sur la page) serait rajout�

Rapidit� d'ex�cution
- utiliser les simples quotes avec du texte, et toujours concat�ner lorsqu'il y a une variable
- pour la concat�nation, utiliser les virgules � la place des points (ne fonctionne que avec echo, et pas avec print, ni pour les concat�nations entre variables... et il ne faut pas entourer le texte de parenth�ses)
- �viter les for... les while avec une indentation a l'int�rieur sont sensiblement plus rapides
- �viter l'op�rateur ternaire ou les switch... pr�f�rez un "if" qui n'est pas forc�ment plus difficile a comprendre, et qui est sensiblement plus rapide
- si vous voulez rajouter quelque chose a la suite d'une variables, utilisez la syntaxe "$variable .= 'bonjour';" au lieu de "$variable = $variable . 'bonjour';", et m�me chose pour les indentations : "+=" ou "-="
- �viter les regex... tr�s lourdes... dans la mesure du possible, utilisez un str_replace au lieu d'un preg_replace, et ainsi de suite !

Facilit� de relecture
- INDENTER !!!
- donner des noms explicites aux variables
- comme dit plus haut, ne pas utiliser un "SELECT *"
- mettre des commentaires, et pr�ciser au d�but du fichier sous quelle configuration il a �t� test� (register globals ? short tags ? magic quotes ? version de php ? version de mysql ?)

Bons r�flexes
- faire des benchmarks au niveau de la rapidit� d'ex�cution si vous avez un doute
- si vous avez une t�che longue a faire, demandez vous si cr�er une interface (plus ou moins automatis�e) ne vous faciliterait pas la vie
06/09/2005, 16h11
sekaijin
Citation:

Envoy� par iubito

Citation:

Envoy� par _Gabriel_

salut,

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

Code:

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

ca c'est pas bon!!!

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

en fait en th�orie tous les arguments du for son �valu� � chage passage de la boucle.
si sizeof ($arr) vaut 10 tu vas passer 10 fois dan sla boucle est tu vas 10 fois �valuer $i<sizeof($arr) tu vas donc appeler 10 fois la fonction

alors que si tu calcule la valeur avant sizeofarr = sizeof($arr) tu ne teste que $i<$sizeofarr 10 fois mais tu n'appelle la fonction qu'une fois.

je ne sais pas ce qu'il en est du moteur zend de php mais certain compilateur savent optimiser ce genre de chose et n'appelle la fonction qu'une fois.

de fa�on g�n�rale pas de fonction dans l'argument d'une boucle.
Code:

1 2 while (mafonction()) { ....}
est l'�quivalent (ce qui est ex�cut�) que
Code:

1 2 3 4 5 $continuer = mafonction(); while ($continuer) { ... $continuer = mafonction(); }
idem pour toutes les formes de boucles.
la deuxi�me forme montre bien que mafonctio est appel� autant de fosi qu'elle retournera vrai + une.
on vois bien qu'elle est dans la boucle.
A+JYT
06/09/2005, 22h02
genova

Il faudrait testern j'ai d�j� eu des cas en C ou le code mettait quelques secondes de plus car je mettais justement un strlen() dans la condition.

cependant ne pas oublier que PHP est un langage interpr�te, il y a de tr�s forts chances que le r�sultat soit mis en cache et non recalcul� � chaque fois, en tout cas si j'avais programm� PHP c'est comme ca que j'aurais fait donc les d�veloppeurs ont surement eu cette id�e.
07/09/2005, 17h23
sekaijin

c'est plus compliqu� que mettre en cache il faut s'assurer que dans le corps de la boucle les arguments de la fonction appel� dans le test ne change pas.

il faut aussi s'assurer qu'il n'y a pas d'effet de bord. la fonction appel� dans la condition utilise peut �tre des param�tres globaux qui pourraient changer de valeur dans le corps.

bref il faut assurer l'ind�pendence du r�sultat de la fonction dans la contion de l'algo du corp.

ce genre d'analyse est particuli�rment difficile � faire. et je ne suis pas du tout sur que php sache le faire.

plus probablement il est possible que le moteur zend pour un certain nombre de fonctions pr�d�finie sache s'assurer de l'ind�pendance et donc mettre en cache.
si c'est le cas c'est dans des cas tr�s particulier.

A+JYT
07/09/2005, 21h31
genova

Oui en fait tu as probablement raison. Les variables PHP sont probablement dans une listes chain�es, et je me disais qu'il sufirait peut �tre simplement de d�finir un flag dans cette structure, qu'on met � TRUE d�s que la variable recoit une modification. Si la variable n'est pas modifi�e dans la boucle le flag reste � FALSE, et le for () par exemple n'a pas besoin de recalculer cette variable. C'est un peu id�aliste mais c'est surement faisable, mais comme tu le dit je doute PHP finalement l'ai fait, il y a beaucoup de param�tres � prendre en compte :?
07/09/2005, 23h16
Rom_1
Bon topic,

juste un point � propos de MySQL et PHP : les moteurs de base de donn�e sont fait pour structurer/organiser/formater les donn�es. Donc ils sont optimis�s pour �a, et le font plus vite que PHP.
Comme cela a d�j� �t� dit, mieux vaut utiliser SQL plut�t que PHP pour ces t�ches, et quelques fonctionnalit�es 'avanc�es' de SQL peuvent �tre fort utiles :

*les jointures
*les requ�tes imbriqu�es (� partir de MySQL 4.1, et pour certaines formes 4.0) : remplace plusieurs requ�tes � la suite par 1 seule
Code:

1 2 3 SELECT champs1, champs2, etc... FROM table WHERE id = (SELECT id FROM autre_table WHERE...) ;
*les transactions (�a c'est plut�t pour la s�curit�), mais faire un commit apr�s ses requ�tes c'est toujours mieux
*pour les probl�mes de base de donn�es bloqu�e par un script : les locks (verrous), mettre un lock en lecture/ecriture sur une ligne plut�t que sur la table enti�re

Pour un script qui utilise intens�ment les bdd, je pense que c'est sur les connexions qu'il faut se concentrer : �a peut gagner beaucoup de temps.

Le mode de connexion peut aussi jouer un r�le : si la base de donn�e est locale (sur le m�me serveur PHP), on peut se connecter avec un socket plut�t qu'en TCP, je crois que c'est plus rapide.

Voil�, si quelqu'un veut bien compl�ter/corriger ce que j'ai �crit ...

--
Rom_1
08/09/2005, 18h53
genova

Les bases de donn�es sont effectivement faites pour formater les donn�es, n�anmoins un cache PHP avec un tableau � inclure �vitera de :
1) Faire une requ�te vers le serveur SQL (ce qui peut �tre important dans certains cas)
2) Avoir les donn�es directement dans le tableau sans se taper un d�placement de pointeur ligne par ligne avec un truc genre mysql_fetch_array()
27/11/2005, 02h00
FFF

je viens de surfer sur ce thread en �tant s�r de trouver ce que je vais annoncer. Et non !!!! Grande surprise (ah moins que ma fonction de recherche de IE me joue des tours, dans ce cas l� DSL) je n'ai pas trouv� l'une des plus grandes optimisations concernant les bases de donn�es :

Code:

mysql_pconnect()

Pr�vu sp�cialement pour des sites web comme developpez.com avec bcp de forums de users de postes donc de bases de donn�es.

Indispensable en tous les cas !
27/11/2005, 02h05
siddh

c'est effectivement un plus mais ca peut avoir des inconvenients, si tu as droit a 20 connections simultan�es et que tu fais du pconnect, tu seras limit� a 20 users sur ton site alors que sans le pconnect, tu pourras en avoir plus car ils interrogeront pas tous la base en meme temps ;)
27/11/2005, 11h05
FFF

Citation:

Envoy� par siddh

c'est effectivement un plus mais ca peut avoir des inconvenients, si tu as droit a 20 connections simultan�es et que tu fais du pconnect, tu seras limit� a 20 users sur ton site alors que sans le pconnect, tu pourras en avoir plus car ils interrogeront pas tous la base en meme temps ;)

je ne suis pas d'accord avec toi :

Citation:

Premi�rement, lors de la connexion, la fonction essaie de trouver une connexion permanente d�j� ouverte sur cet h�te, avec le m�me nom d'utilisateur et de mot de passe. Si une telle connexion est trouv�e, son identifiant est retourn�, sans ouvrir de nouvelle connexion.

Le seul inconv�nient est au niveau de la s�curit� du serveur mysql... mais y a moyen je pense de s�curisr cette connexion (filtre IP des requ�tes...).
27/11/2005, 11h19
siddh

je me suis mal exprim�.

Citation:

Notez que les connexions persistantes ont quelques inconv�nients si vous h�bergez une base de donn�es, dont le nombre maximal de connexion risque d'�tre atteint par les connexions persistantes. Si votre base de donn�es accepte jusqu'� 16 connexions simultan�es et que, 17 processus essaient de se connecter, le dernier restera sur la touche. S'il y a des erreurs dans les scripts qui ne permettent pas de fermer la connexion (par exemple, une boucle infinie), votre serveur sera rapidement engorg�. V�rifiez la documentation de votre base de donn�es pour savoir comment elle traite les connexions inactives ou abandonn�es.
27/11/2005, 11h22
FFF

Oui en fait j'ai pas lu toute la doc, tu as raison effectivement pour les connexions simultan�es siddh.
Mais tu peux inclure dans le code une petite pause (qq milisecondes) au script, le temps que les autres lib�re la connexion, comme cela les autres requ�tes ne perdent pas en vitesse d'ex�cution et sont m�mes incit�es � terminer rapidement leur process.
Pour avoir 20 connexions ou requ�tes simultann�es sur un serveur web sur un site comme dvez.com je dirais (� vu de nez) qu'il faut peut -�tre une centaine d'utilisateurs (suivant la taille et le nombre des requ�tes) qui consultent le site, donc c'est pas si contraignant que cela (probabilit�s de clics simultan�s).

En fait ce qu'ils disent de retenir de cette fonction sur la doc :

Citation:

R�sumons-nous : les connexions persistantes ont �t� d�finies pour avoir les m�mes fonctionnalit�s que les connexions non persistantes. Les deux types de connexions sont parfaitement interchangeables, et n'affecteront pas le comportement de votre script : uniquement son efficacit�.
27/11/2005, 11h28
siddh

oui, c'est un plus mais faut juste faire gaffe.
Si tu as un d�di�, tu fais ce que tu veux.
Dans le cadre d'un h�bergement mutualis�, ca peut peut etre coincer.

Personnellement je n'utilise pas pconnect car je me suis fais une classe d'abstraction (que je vais modifier pour utiliser PDO) qui est un singleton donc je me fais ma persistance tout seul.
27/11/2005, 11h31
FFF

�a a l'air int�ressant, tu peux expliciter ta d�marche (PDO?) en quelques mots ?!
27/11/2005, 11h41
siddh

Pdo est une couche d'abstraction pour php 5:
http://fr3.php.net/pdo
27/11/2005, 11h51
FFF

Autre astuce :

Citation:

resource mysql_unbuffered_query ( string query [, resource link_identifier] )

mysql_unbuffered_query() envoie la requ�te SQL query au serveur MySQL identifi� par link_identifier, sans pr�parer les r�sultats pour la lecture, comme le fait mysql_query(). D'une part, cela r�duit consid�rablement la consommation de m�moire par MySQL, lorsque les requ�tes g�n�rent des r�sultats de grande taille. D'autre part, vous pourrez utiliser les r�sultats d�s que la premi�re ligne aura �t� lue : pas besoin d'attendre que la requ�te ait compl�tement �t� ex�cut�e. Lorsque vous utilisez de multiples connexions � MySQL, vous devez sp�cifier le param�tre optionnel link_identifier.
27/11/2005, 11h53
FFF

Citation:

Envoy� par siddh

Pdo est une couche d'abstraction pour php 5:
http://fr3.php.net/pdo

je ne vois pas le rapport avec les connexions persistantes...
27/11/2005, 12h13
siddh

ben tu met ca dans un objet dont tu te fais un singleton
27/11/2005, 12h30
FFF

ok je viens de lire une page int�ressante :
http://qwix.media-box.net/index.php/...ingletonEnPhp5

je pense que c'est le principe de ce que tu disais plus haut.

Mais du coup, connaissant la programmation OO en java mais peu celle de php, je me pose la question de la dur�e de vie d'un objet en php ?!
Ce que j'ai en t�te pour l'instant, c'est que pour tout code php, la dur�e de vie des toutes les instances (variables, objets...) est �gale � celle de l'ex�cution du script php, est ce bien cela ?
Si c'est le cas, alors je vais me r�p�ter en disant qu'il n'y a pas d'�quivalents entre mysql_pconnect() et la connexion mysql via les objets PDO !
Si je me trompe alors explique moi car l� je vois pas comment un objet php peut persister... (c'est d'ailleurs ce qui me fait douter de l'efficacit� de la POO en php) sauf en utilisant les sessions (of course !) mais bon si faut d'abord mettre �a pour avoir �a...

Sinon le coup des singletons est astucieux !
27/11/2005, 12h40
siddh

oui tu met tes objets en session ;)
27/11/2005, 12h47
FFF

DSL je suis pas convaincu par PDO (j'aime pas les sessions c'est un peu lourd pour peu de choses bien que tr�s pratique j'avoue), je pr�f�re mysql_pconnect()

Merci pour tes explications en tout cas ! :)
27/11/2005, 13h33
FFF

pour expliciter ce que je viens de dire pr�cedemment.

Dans ce cas l� les sessions demandent trop de ressources au syst�me (� confirmer).En tout cas je pr�f�re les r�server uniquement pour avoir un identifiant de connexion sur le site. Ensuite rien n'emp�che de faire un �quivalent "programmation orient�e" objet en utilisant les bases de donn�es comme moyen d'acc�s aux membres des objets (qui seraient enfait des tables...) et de remplacer les m�thodes par des fonctions classiques.
29/11/2005, 15h21
FFF

une autre astuce de performances pour ex�cuter un script php distant :
privil�giez la fonction fsockopen() ou stream_socket_client() vous perdez du temps en programmation, mais gagnez sur le temps d'ex�cution de votre script, voir le post suivant :

http://www.developpez.net/forums/showthread.php?t=73445
29/11/2005, 21h02
Kioob

Tu t'avances beaucoup je trouve... :?

Pour les connexions persistantes, c'est quasiment inutilisable en mutualis�. Et sur un d�di�, il faut configurer MySQL pour accepter un grand nombre de connexion simultan�es... ce qui veut dire beaucoup moins de m�moire disponible pour chacune de ces connexions, ce qui implique g�n�ralement pas mal d'acc�s disques suppl�mentaires... bref, dans ces conditions, �a empire largement les choses.

Donc comme sp�cifi� dans la doc, �a peut �tre tr�s interessant, mais seulement dans certains contextes assez particuliers.

Cot� connexion persistante en session, � ma connaissance PHP coupera la connexion � la fin du script de toutes fa�ons... donc lors de la r�-instanciation il faut se reconnecter... au final, je ne vois pas le gain.

Pour mysql_query_unbuffered, oui, effectivement. Mais ce n'est pas adapt� � toutes les utilisations : il est par exemple impossible de faire des appels imbriqu�s avec cette fonction.

Pour ce qui est de ton ouverture par socket, il serait bien plus malin de faire une requete HEAD si tu ne souhaites pas r�cup�rer le contenu...
30/11/2005, 13h14
FFF

Citation:

Envoy� par Kioob

Tu t'avances beaucoup je trouve... :?

Oui mais c'est fond� !!

Citation:

Pour les connexions persistantes, c'est quasiment inutilisable en mutualis�. Et sur un d�di�, il faut configurer MySQL pour accepter un grand nombre de connexion simultan�es... ce qui veut dire beaucoup moins de m�moire disponible pour chacune de ces connexions, ce qui implique g�n�ralement pas mal d'acc�s disques suppl�mentaires... bref, dans ces conditions, �a empire largement les choses.

Donc comme sp�cifi� dans la doc, �a peut �tre tr�s interessant, mais seulement dans certains contextes assez particuliers.

Cot� connexion persistante en session, � ma connaissance PHP coupera la connexion � la fin du script de toutes fa�ons... donc lors de la r�-instanciation il faut se reconnecter... au final, je ne vois pas le gain.

Relis bien la doc s'il te pla�t !

Citation:

Pour ce qui est de ton ouverture par socket, il serait bien plus malin de faire une requete HEAD si tu ne souhaites pas r�cup�rer le contenu...

J'ai fais les tests, il n'y a aucun apport significatif avec le HEAD. De toutes fa�ons mon script ne r�cup�rant pas la r�ponse que je fasse GET ou HEAD c'est pareil apparament le serveur web ne fait aucune priorit� sur les diff�rentes requ�tes. Dire que cela aurait �t� bien plus malin de faire un HEAD, je trouve que tu es un peu dur avec moi !
Mon pb n'�tait pas sur la requ�te HTTP, mais sur la fa�on d'ex�cuter un script distant !
01/12/2005, 01h48
Kioob

Citation:

Envoy� par FFF

Oui mais c'est fond� !!

Et bien �a n'engage que moi, mais je dirais : absoluement pas.

Citation:

Relis bien la doc s'il te pla�t !

Je me suis peut �tre mal exprim�, mais je maintiens � 100% mes dires.

Citation:

J'ai fais les tests, il n'y a aucun apport significatif avec le HEAD. De toutes fa�ons mon script ne r�cup�rant pas la r�ponse que je fasse GET ou HEAD c'est pareil apparament le serveur web ne fait aucune priorit� sur les diff�rentes requ�tes. Dire que cela aurait �t� bien plus malin de faire un HEAD, je trouve que tu es un peu dur avec moi !
Mon pb n'�tait pas sur la requ�te HTTP, mais sur la fa�on d'ex�cuter un script distant !

Parce que tu ne tiens pas compte des ressources sur le serveur : m�me si tu ne lis pas le contenu retourn� par le script, il se trouve que tu l'as demand�. Donc Apache et PHP auront d�j� tout mis en oeuvre pour g�n�rer ce fameux contenu. M�me si le "ignore_user_abort" n'est pas activ�, le traitement aura d�but�...
De plus, un script bien fait ne fera pas l'affichage dans le cas d'une requete HEAD, il se contentera du comportement attendu par le script.
01/12/2005, 11h37
FFF

pour le mysql_pconnect(), si tu penses qu'il vaut mieux cr�er de nouvelles connexions � chaque ex�cution du script, c'est toi qui voit.
Pour l'histoire du HEAD, ce que tu dis n'a pas de sens et est faux, c'est juste une histoire d'�conomie de bande passante, et cela n'affecte pas les ressources mobilis�es par le seveur lamp/wamp (comment veux tu r�cup�rer seulement l'ent�te d'une page php sans attendre la fin de son ex�cution et sans m�me conna�tre la totalit� de son contenu ??? :roll: )
voil� une autre doc :
http://clx.anet.fr/spip/article.php3?id_article=111
01/12/2005, 12h21
Kioob
Citation:

Envoy� par FFF

pour le mysql_pconnect(), si tu penses qu'il vaut mieux cr�er de nouvelles connexions � chaque ex�cution du script, c'est toi qui voit.

Bon, je r�-explique : les connexions persistantes fonctionnent par PROCESSUS, c'est � dire que si ton Apache est configur� pour tourner avec 200 processus, tu auras potentiellement 200 connexions persistantes ouvertes vers ton MySQL. Et ce, pour un seul couple LOGIN/PASS.
Dans le cas d'un serveur mutualis�, avec une cinquantaine de sites, on monte donc � 1000 connexions simultan�es ouvertes.

Donc ton serveur MySQL, qui en temps normal d�ssert 10 connexions simultan�es, auxquelles il alloue par exemple 256Mo de donn�es (soit 25Mo chacune) pour les diff�rents buffers va donc se retrouver avec 1000 connexions se partageant ces m�mes 256Mo (soit 256Ko chacune...). Bref, �a va coincer.
Plusieurs probl�mes peuvent arriver :
- si PHP limite le nombre de connexions persistantes, certains scripts ne pourront pas du tout se connecter
- si MySQL limite le nombre de connexions simultan�es, certains scripts ne pourront pas du tout se connecter
- si MySQL n'est pas configur� pour accepter autant de connexions, il va consommer trop de m�moire, l'OS va swapper � mort
- si MySQL est configur� pour accepter autant de connexions sans toutefois avoir 10Go de m�moire sur la machine, cela veut dire que les threads auront moins de m�moire disponible, et feront donc plus d'acc�s disques qu'en temps normal.
Au final, les 50ms gagn�s sur le temps de connexion cot� PHP, tu les perds souvent cot� MySQL au centuple.

Avant de mettre en place les connexions persistantes, il faut donc s'assurer qu'Apache, PHP et MySQL soient configur�s pour. Et ce n'est certainement pas en faisant 3/4 tests que tu le sauras.

Citation:

Pour l'histoire du HEAD, ce que tu dis n'a pas de sens et est faux, c'est juste une histoire d'�conomie de bande passante, et cela n'affecte pas les ressources mobilis�es par le seveur lamp/wamp

Merci... je veux bien croire que je n'ai pas �t� clair et/ou que tu n'ais pas compris, mais de l� � affirmer que cela n'a aucun sens et que c'est faux, il y a de la marge...

Citation:

(comment veux tu r�cup�rer seulement l'ent�te d'une page php sans attendre la fin de son ex�cution et sans m�me conna�tre la totalit� de son contenu ??? :roll: )

Perso dans mes scripts j'ai entre autre �a, et depuis des ann�es :
Code:

1 2 if( @ $_SERVER['REQUEST_METHOD']==='HEAD' ) exit;
Ce petit bout de code est appel� automatiquement par la classe g�rant les ent�tes HTTP, qui est utilis�e juste avant les traitements d'affichage.
Le script arr�te simplement son �x�cution lorsqu'il voit que l'affichage n'est pas requis.

Il y a fort � parier que les classes comme JPCache g�rent �galement ces m�canismes de base du protocole HTTP.

Citation:

voil� une autre doc :
http://clx.anet.fr/spip/article.php3?id_article=111

Merci, mais je pr�f�re m'en tenir � la RFC.
01/12/2005, 12h48
FFF

Ben �coute puisque tu as l'air si s�r de toi �cris donc sur le site php.net � la rubrique des connexions persistantes �a permettrait d'informer les lecteurs des limites sur mysql_pconnect() ce qui est int�ressant ! (bien que j'ai rien compris � ta d�monstration d�sol� :( ) et au moins il y aurait un commentaire en fran�ais !

Voir 40 message(s) de cette discussion en une page