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 !