> Pour revenir sur la question des mysql_connect, il y a des gens qui
> travaillent avec plusieurs bases de données différentes et qui ont
> donc des connections DIFFERENTES et donc, qui ne veulent/peuvent
> pas réutiliser par défault la dernière connection automatique.
Ce n'est pas de ça que je te parle.
Je te dis simplement que quand tu fais plusieurs ouvertures de connexion avec les mêmes paramètres, tu récupères un identifiant vers la même connexion. Ca n'a rien à voir avec le principe de réutilisation de la dernière connexion ouoverte (ce qui effectivement est une mauvaise idée parce que ça va peter dès qu'on a besoin de plusieurs sources différentes).
> Donc avant je faisait, en gros un connect() à chaque accès,
> maintenant je 'trie' les connections pour n'ouvrir que des connexions
> nécessaires. Dans tes scripts tu ne donnes pas un identifiant de
> connexion ? tu laisses php prendre par défault le dernièr utilisé ?
> arggg
J'ai dit ça ?
Non, j'utilise tout comme toi les identifiants de connexion. Je reprend ton exemple :
> fait une connection host1 - base1 -> print id : Ressourceid#4 (par
> ex)
> ensuite encore host1 - base1 -> print id : Ressourceid#4 (normal,
> suivant ta théorie car php réutilise la dernière connection)
Oui. D'ailleurs si jamais tu ne me crois pas, tu peux lire la doc :
""" Si un deuxième appel est fait à mysql_connect() avec les mêmes arguments, aucune nouvelle connexion ne sera établie, mais plutôt, l'identifiant de la connexion de la connexion déjà ouverte sera retourné."""
> MAIS host1 - base 2 -> print id : Ressourceid#4 (je ne comprend
> pas !!!, ce n'est pas le même connexion, et tu n'a pas assez aux
> mêmes tables.)
Ben oui, mais regardes ce que tu fais avec ton code :
$link1 = mysql_connect('host1') ;
mysql_select_db('base1', $link1) ;
$link2 = mysql_connect('host1') ;
// là $link2 est bien le meme que le précédent $link1,
// d'ailleurs tu l'as vu toi même
mysql_select_db('base2', $link2) ;
// tu as toujours la meme connexion
// mais tu viens de lui demander de changer de base
// donc forcément tu ne vois pas les memes tables
// maintenant essayes de lister les tables sur $link1
// tu verras qu'elles ont changes aussi.
Si tu veux avoir deux connexions distinctes, tu as un paramètre spécifique sur mysql_connect() qui dit explicitement "j'ai déjà une connexion avec ces paramètres mais j'en veux une nouvelle, pas la meme"
> Donc avant je faisait, en gros un connect() à chaque accès,
> maintenant je 'trie' les connections pour n'ouvrir que des
> connexions nécessaires.
On s'est bien compris, et moi (ainsi que la doc) je te dis que même auparavant, tu n'ouvrais que les connexions nécessaires et que tu ne faisais jamais de doublon (sauf si tu fermais la connexion explicitement ou que tu forcais le doublon avecle paramètre adéquat, mais là ça devient volontaire)
> Je ne sais pas, comment cela ce fait-il que en c
Peut être parce que le PHP n'est pas identique au C ? qu'un langage compilé n'a pas les mêmes avantages et inconvénients qu'un langage interprété ? que avec la lenteur globale de PHP le changement de contexte d'une fonction est négligeable ou en tout cas l'argement réduit par rapport à ton chiffre de x1/x10 ?
Pour un simple exemple, en PHP passer un argument explicitement par référence est plus lent que le passer par copie. Et *paf* pour les idées reçues et le "oui mais en C ...."
Autre exemple ? en PHP l'accès à une constante est plus lent que l'accès à une variable, et re-*paf* pour les idées reçues et le "oui mais en C ..."
Bref, se méfier beaucoup des légendes urbaines sur les performances. Et principalement dans PHP qui a ses propres logiques et peu de gens qui connaissent vraiment le fonctionnement interne.
Le fait que tu gagnes parfois des perf sur certains inline en C ne veut pas dire qu'il faut faire la même opération en PHP, ou que tu vas y gagner assez (comprendre: assez pour que l'effet positif des performances contrebalance l'effet nagatif de la duplication de code et de la relecture)
> Oui, oui allons dans les " blabla $var bliobli..." oui c'est cool, même
> avec un "select * from base where id= $_POST['login'] "cela va
> plus vite à coder et plus vite à analyser et... un peu goret qd même.
Ah ?
entre les deux codes suivant, lequel est le plus clair, le plus goret, et pourquoi ? enfin en retirant ton exemple biaisé qui utilise directement une entrée utilisateur sans filtrage et sans echappement bien entendu.
V1 :
$id = calcule_filtre_et_recupere_id() ;
$date = calcule_filtre_et_recupere_date() ;
$sql = "SELECT * FROM base WHERE id=$id AND date<'$date'" ;
V2:
$id = calcule__filtre_et_recupere_id() ;
$date = calcule_filtre_et_recupere_date() ;
$sql = 'SELECT * FROM base WHERE id='.$id.' AND date<\''.$date.'\''" ;
Niveau clarté c'est sans appel je choisis la V1
Niveau performances c'est kifkif mais si tu tiens à calculer les demi-microsecondes la V1 est plus rapide
Niveau goret ... tu m'expliques en quoi la V1 est goret ?
> Réutiliser du code existant ? cela voudrait dire le passer en revue
> pour qu'il devienne 'trusted' pour moi et mon employeur (autant de
> temps que de le réécrire), si je suis employé et que je fournis du
> code 'emprunté' à d'autres, demain, mon travail sera 'donné' à
> d'autre.
Si ta valeur ajoutée c'est de refaire depuis zéro ce qui existe ailleurs et qui marche je conçois que tu te fasses du souci pour ton travail.
Moi ma valeur ajoutée c'est justement de faire ce qui n'existe pas, de réutiliser pour adapter ou étendre.
D'ailleurs, ça mis à part, je suis étonné que sur un site proche du libre et de la communauté, on ne voit pas l'intérêt à mutualiser les codes et à réutiliser plutot que tout refaire dans son coin.
Pour reprendre ton exemple, si j'ai l'assurance qu'un CMS, un outil de blog, un DHAL, une classe de manipulation Excel ou je ne sais quoi d'autre correspond à mon besoin et à ma licence et à mes critères qualités, je ne me priverai pas de le réutiliser/modifier pour reproter mon travail sur ma valeur ajouté.
Si c'est pour refaire quelque chose qui existe déjà ils n'ont justement pas besoin de moi.
> Alors Non, ce ne sont pas des applis à 200 euros, mais bien plus,
> si tu veux travailler pour pas chèr avec de la réintégration du travail
> d'autres, c'est un choix/obligation du marché. A ce niveau là, les
> pays de l'est vont ceuillir ce marché très facilement.
Je préfère faire des applications complètes, chères, de qualité, avec de la réutilisation ;)
Le fait de réutiliser (là où c'est pertinent) me permet justement de faire des applis plus complètes et de meilleure qualité, pas forcément de dire "j'en fais moins".
Si tu fais des applications à 200ke qui ne font qu'à peine plus qu'e ce que font les briques dispo en LL parce que tu perd ton temps à tout réécrire, c'est plutot toi qui va avoir du mal à te reveiller. Parce que ton marché de l'est lui il va justement te proposer la même chose pour 1000 fois moins cher puisqu'il ne fera que les ajouts/modifs à partir de l'existant, pas tout le développement.
Quoi que dans ma boite l'externalisation elle est au Maroc, mais la problématique est la même. Ici on coute plus cher, c'est pour faire ce qu'on ne peut pas faire ailleurs : l'adaptation et la spécialisation des applicatifs (où il faut être proche du client), recoder des briques le Maroc peut le faire, ils ont des gens largement aussi compétents qu'ici (contrairement aux idées reçues du type "moi je fais du bon code d'expert, je ne suis pas en concurrence").
> Je ne rentre même pas dans la réthorique de la course à la
> puissance, pourquoi me faire chier à optimiser, y des proc bi-core
> qui arrivent.
Il s'agit juste de faire de efforts utiles. Quand on gagne millisecondes par jour après avoir faire une revue/modification complète de code (donc probablement plus d'une semaine) et avec tous les risques d'erreur que ça entraine (donc les temps de test, recette, etc.) je connais très peu d'entreprises qui trouvent utile de faire le pas (en fait je n'en connais aucune).
Le pire c'est quand, à force de vouloir optimiser tout et n'importe quoi sans connaitre le langage on fini par faire un travail inutile, type ce que tu fais avec les mysql_connect().
Non, sérieux, ton code et ton architecture sont si parfaits que tu en es à optimiser ce genre de chose pour des gains si modestes ? tu es sûr de ne pas avoir assez de travail ailleurs plus utile/pressé pour laisser ça de coté ?
[^] # Re: contre
Posté par Éric (site web personnel) . En réponse au journal Petition MYSQL chez Nerim. Évalué à 3.
> travaillent avec plusieurs bases de données différentes et qui ont
> donc des connections DIFFERENTES et donc, qui ne veulent/peuvent
> pas réutiliser par défault la dernière connection automatique.
Ce n'est pas de ça que je te parle.
Je te dis simplement que quand tu fais plusieurs ouvertures de connexion avec les mêmes paramètres, tu récupères un identifiant vers la même connexion. Ca n'a rien à voir avec le principe de réutilisation de la dernière connexion ouoverte (ce qui effectivement est une mauvaise idée parce que ça va peter dès qu'on a besoin de plusieurs sources différentes).
> Donc avant je faisait, en gros un connect() à chaque accès,
> maintenant je 'trie' les connections pour n'ouvrir que des connexions
> nécessaires. Dans tes scripts tu ne donnes pas un identifiant de
> connexion ? tu laisses php prendre par défault le dernièr utilisé ?
> arggg
J'ai dit ça ?
Non, j'utilise tout comme toi les identifiants de connexion. Je reprend ton exemple :
> fait une connection host1 - base1 -> print id : Ressourceid#4 (par
> ex)
> ensuite encore host1 - base1 -> print id : Ressourceid#4 (normal,
> suivant ta théorie car php réutilise la dernière connection)
Oui. D'ailleurs si jamais tu ne me crois pas, tu peux lire la doc :
""" Si un deuxième appel est fait à mysql_connect() avec les mêmes arguments, aucune nouvelle connexion ne sera établie, mais plutôt, l'identifiant de la connexion de la connexion déjà ouverte sera retourné."""
> MAIS host1 - base 2 -> print id : Ressourceid#4 (je ne comprend
> pas !!!, ce n'est pas le même connexion, et tu n'a pas assez aux
> mêmes tables.)
Ben oui, mais regardes ce que tu fais avec ton code :
$link1 = mysql_connect('host1') ;
mysql_select_db('base1', $link1) ;
$link2 = mysql_connect('host1') ;
// là $link2 est bien le meme que le précédent $link1,
// d'ailleurs tu l'as vu toi même
mysql_select_db('base2', $link2) ;
// tu as toujours la meme connexion
// mais tu viens de lui demander de changer de base
// donc forcément tu ne vois pas les memes tables
// maintenant essayes de lister les tables sur $link1
// tu verras qu'elles ont changes aussi.
Si tu veux avoir deux connexions distinctes, tu as un paramètre spécifique sur mysql_connect() qui dit explicitement "j'ai déjà une connexion avec ces paramètres mais j'en veux une nouvelle, pas la meme"
> Donc avant je faisait, en gros un connect() à chaque accès,
> maintenant je 'trie' les connections pour n'ouvrir que des
> connexions nécessaires.
On s'est bien compris, et moi (ainsi que la doc) je te dis que même auparavant, tu n'ouvrais que les connexions nécessaires et que tu ne faisais jamais de doublon (sauf si tu fermais la connexion explicitement ou que tu forcais le doublon avecle paramètre adéquat, mais là ça devient volontaire)
> Je ne sais pas, comment cela ce fait-il que en c
Peut être parce que le PHP n'est pas identique au C ? qu'un langage compilé n'a pas les mêmes avantages et inconvénients qu'un langage interprété ? que avec la lenteur globale de PHP le changement de contexte d'une fonction est négligeable ou en tout cas l'argement réduit par rapport à ton chiffre de x1/x10 ?
Pour un simple exemple, en PHP passer un argument explicitement par référence est plus lent que le passer par copie. Et *paf* pour les idées reçues et le "oui mais en C ...."
Autre exemple ? en PHP l'accès à une constante est plus lent que l'accès à une variable, et re-*paf* pour les idées reçues et le "oui mais en C ..."
Bref, se méfier beaucoup des légendes urbaines sur les performances. Et principalement dans PHP qui a ses propres logiques et peu de gens qui connaissent vraiment le fonctionnement interne.
Le fait que tu gagnes parfois des perf sur certains inline en C ne veut pas dire qu'il faut faire la même opération en PHP, ou que tu vas y gagner assez (comprendre: assez pour que l'effet positif des performances contrebalance l'effet nagatif de la duplication de code et de la relecture)
> Oui, oui allons dans les " blabla $var bliobli..." oui c'est cool, même
> avec un "select * from base where id= $_POST['login'] "cela va
> plus vite à coder et plus vite à analyser et... un peu goret qd même.
Ah ?
entre les deux codes suivant, lequel est le plus clair, le plus goret, et pourquoi ? enfin en retirant ton exemple biaisé qui utilise directement une entrée utilisateur sans filtrage et sans echappement bien entendu.
V1 :
$id = calcule_filtre_et_recupere_id() ;
$date = calcule_filtre_et_recupere_date() ;
$sql = "SELECT * FROM base WHERE id=$id AND date<'$date'" ;
V2:
$id = calcule__filtre_et_recupere_id() ;
$date = calcule_filtre_et_recupere_date() ;
$sql = 'SELECT * FROM base WHERE id='.$id.' AND date<\''.$date.'\''" ;
Niveau clarté c'est sans appel je choisis la V1
Niveau performances c'est kifkif mais si tu tiens à calculer les demi-microsecondes la V1 est plus rapide
Niveau goret ... tu m'expliques en quoi la V1 est goret ?
> Réutiliser du code existant ? cela voudrait dire le passer en revue
> pour qu'il devienne 'trusted' pour moi et mon employeur (autant de
> temps que de le réécrire), si je suis employé et que je fournis du
> code 'emprunté' à d'autres, demain, mon travail sera 'donné' à
> d'autre.
Si ta valeur ajoutée c'est de refaire depuis zéro ce qui existe ailleurs et qui marche je conçois que tu te fasses du souci pour ton travail.
Moi ma valeur ajoutée c'est justement de faire ce qui n'existe pas, de réutiliser pour adapter ou étendre.
D'ailleurs, ça mis à part, je suis étonné que sur un site proche du libre et de la communauté, on ne voit pas l'intérêt à mutualiser les codes et à réutiliser plutot que tout refaire dans son coin.
Pour reprendre ton exemple, si j'ai l'assurance qu'un CMS, un outil de blog, un DHAL, une classe de manipulation Excel ou je ne sais quoi d'autre correspond à mon besoin et à ma licence et à mes critères qualités, je ne me priverai pas de le réutiliser/modifier pour reproter mon travail sur ma valeur ajouté.
Si c'est pour refaire quelque chose qui existe déjà ils n'ont justement pas besoin de moi.
> Alors Non, ce ne sont pas des applis à 200 euros, mais bien plus,
> si tu veux travailler pour pas chèr avec de la réintégration du travail
> d'autres, c'est un choix/obligation du marché. A ce niveau là, les
> pays de l'est vont ceuillir ce marché très facilement.
Je préfère faire des applications complètes, chères, de qualité, avec de la réutilisation ;)
Le fait de réutiliser (là où c'est pertinent) me permet justement de faire des applis plus complètes et de meilleure qualité, pas forcément de dire "j'en fais moins".
Si tu fais des applications à 200ke qui ne font qu'à peine plus qu'e ce que font les briques dispo en LL parce que tu perd ton temps à tout réécrire, c'est plutot toi qui va avoir du mal à te reveiller. Parce que ton marché de l'est lui il va justement te proposer la même chose pour 1000 fois moins cher puisqu'il ne fera que les ajouts/modifs à partir de l'existant, pas tout le développement.
Quoi que dans ma boite l'externalisation elle est au Maroc, mais la problématique est la même. Ici on coute plus cher, c'est pour faire ce qu'on ne peut pas faire ailleurs : l'adaptation et la spécialisation des applicatifs (où il faut être proche du client), recoder des briques le Maroc peut le faire, ils ont des gens largement aussi compétents qu'ici (contrairement aux idées reçues du type "moi je fais du bon code d'expert, je ne suis pas en concurrence").
> Je ne rentre même pas dans la réthorique de la course à la
> puissance, pourquoi me faire chier à optimiser, y des proc bi-core
> qui arrivent.
Il s'agit juste de faire de efforts utiles. Quand on gagne millisecondes par jour après avoir faire une revue/modification complète de code (donc probablement plus d'une semaine) et avec tous les risques d'erreur que ça entraine (donc les temps de test, recette, etc.) je connais très peu d'entreprises qui trouvent utile de faire le pas (en fait je n'en connais aucune).
Le pire c'est quand, à force de vouloir optimiser tout et n'importe quoi sans connaitre le langage on fini par faire un travail inutile, type ce que tu fais avec les mysql_connect().
Non, sérieux, ton code et ton architecture sont si parfaits que tu en es à optimiser ce genre de chose pour des gains si modestes ? tu es sûr de ne pas avoir assez de travail ailleurs plus utile/pressé pour laisser ça de coté ?