Discussion :

[FFF]

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 :

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

[siddh]

je me suis mal exprim�.

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.

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

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

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

[FFF]

�a a l'air int�ressant, tu peux expliciter ta d�marche (PDO?) en quelques mots ?!

[siddh]

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

[FFF]

Autre astuce :

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.

[FFF]

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

je ne vois pas le rapport avec les connexions persistantes...

[siddh]

ben tu met ca dans un objet dont tu te fais un singleton

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

[siddh]

oui tu met tes objets en session

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

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

[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

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

[FFF]

Tu t'avances beaucoup je trouve...

Oui mais c'est fond� !!

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 !

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 !

[Kioob]

Oui mais c'est fond� !!

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

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

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

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.

[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 ??? )
voil� une autre doc :
http://clx.anet.fr/spip/article.php3?id_article=111

[Kioob]

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.

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

(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 ??? )

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

Code :

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

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.

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.

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