Bonjour,
NERIM, FAI français pour les particuliers et les professionnel offre un espace d'hébergement web.
J'organise une pétition pour que NERIM nous propose un serveur MYSQL
dans son espace d'hébergement web.
http://www.PetitionOnline.com/nerimsql/petition.html(...)
Explications :
La base de donnée proposée Postgresql pose problème pour beaucoup des abonnés NERIM, au point de rendre inexploitable cet espace d'hébergement. Postgresql est d'une qualité supérieure à son concurrent MYSQL, mais MYSQL est beaucoup plus largement utilisée. A tel point que la grande majorité des applications WEB ne supportent que MYSQL.
Impossible d'utiliser des applications phares (dotclear [blog], spip [cms], bugzilla [bugtracker] ...) sur l'hébergement de NERIM.
NERIM est sans cesse relançée sur ce sujet et oppose trois arguments :
- Il est possible de se connecter à une base de données externe.
Techniquement c'est vrai (librairie mysql activée) mais en pratique, les autres hébergeurs bloquent l'accès externe à leur base de données.
- "Postgresql est supérieur techniquement". C'est probablement vrai, mais les applications n'utilisent que rarement la couche d'abstration qui permet d'utiliser l'une ou l'autre des bases de données. En clair elles imposent d'utiliser MYSQL.
- "MYSQL est plus difficile à maintenir et monopolisera des ressources"
NERIM est déjà plus cher que ses concurrents. Et les autres hébergeurs s'en sortent bien. Au pire NERIM n'a qu'a proposer cette base en option.
Je propose donc à tous les abonnés NERIM, ou futur abonnés de prendre ce problème récurrent une fois pour toute et de signer cette pétition.
http://www.PetitionOnline.com/nerimsql/petition.html(...)
Ce message a également été posté sur le serveur de news de NERIM
Journal Petition MYSQL chez Nerim
21
sept.
2005
# contre
Posté par BAud (site web personnel) . Évalué à 10.
1. Nerim propose aimablement un hébergement et a fait un choix technique intelligent pour ses utilisateurs. Nerim reste tout de même maître de l'infrastructure qu'il met à disposition
2. ce choix peut permettre de populariser les couches d'abstraction dans de nombreux produits, ce qui a du bon, pourquoi se restreindre à MySQL ?
3. rien n'empêche de choisir un autre hébergement parmi ceux existants (genre pour les projets libres : tf.o, gna.org, sf.net...)
[^] # Re: contre
Posté par spell (site web personnel) . Évalué à 9.
est un "standard" de fait. Je ne comprends pas pourquoi les développeurs n'utilisent pas les couches d'abstrations.
Point 1 : Nerim reste maitre de l'infrastructure, mais ne peux pas ignorer les besoins de ces utilisateurs. Mettre en avant cet espace d'hébergement semble presque hypocrite.
Cette pétition sert à voir le nombre d'utilisateurs intéressés. S'ils sont nombreux, NERIM va nous écouter.
Sinon je fermerais mon bec, et j'utiliserais la solution proposée en point 3.
Par contre voter contre un pétition, c'est pas sympa. Faut laisser au gens le moyen de s'exprimer tout de même ! ;-)
[^] # Re: contre
Posté par Pooly (site web personnel) . Évalué à -4.
Parceque (en vrac ) :
1. C'est lent.
2. Quand y'a un bug, ça fait une couche de plus à débugger.
3. Qu'il faut en avoir l'utilité,
4. Qu'il faut tout de même tester avec les autres bases de données.
5. Parceque MySQL est utilisé sur le web de manière massive.
6. Que les couches d'abstractions ne sont pas standards et autant répandu que l'api MySQL.
7. Qu'il faudrait pousser dotclear et autres à adopter PostgreSQL, ce qui ne doit pas être trop sorcier vu le peu de différences de syntaxe SQL (LIMIT x, OFFSET y). Juste le DDL qui change.
[^] # Re: contre
Posté par Ymage . Évalué à 10.
A mon avis, l'indirection ajouté par une DBAL type ADODB ou Pear::DB est très peu impactante question performance. Et si tu en es à ce genre d'optimisation, ce n'est plus de l'hébergement de pages persos qu'il te faut mais un hébergement professionnel.
2. Quand y'a un bug, ça fait une couche de plus à débugger.
Je crois pouvoir dire que Pear::DB ou ADODB sont suffisamment matures pour considérer que leurs bugs sont aussi courant que ceux contenus dans PHP lui-même.
Il y'a statistiquement plus de bugs dans les applications qui s'appuient dessus.
3. Qu'il faut en avoir l'utilité,
L'utilité ? Le support de la base de données sans se soucier des spécificités du SBGD sous-jacent.
A moins, que tu n'aies vraiment besoin de fonctionnalités non standards et dans ce cas, les pages persos ne sont pas pour toi.
4. Qu'il faut tout de même tester avec les autres bases de données.
Ah bon ? Je croyais que c'était juste pour utiliser avec ton SGBD. En général, la DBAL sert à ne pas se soucier du SGBD mais le cas d'un utilisateur utilisant la même application sur différents environnement est rare.
5. Parceque MySQL est utilisé sur le web de manière massive.
Et il paraît même que IE et Windows sont utilisés de manière massive sur les postes clients.
Vive les généralités inutiles.
6. Que les couches d'abstractions ne sont pas standards et autant répandu que l'api MySQL.
Dans le domaine PHP, il y'en a quelques unes qui tirent leurs épingles du jeux quand même. Et leurs API parfaitement documentées et leur usage répandu.
7. Qu'il faudrait pousser dotclear et autres à adopter PostgreSQL, ce qui ne doit pas être trop sorcier vu le peu de différences de syntaxe SQL (LIMIT x, OFFSET y). Juste le DDL qui change.
Là, on est d'accord mais quitte à supporter plusieurs SGBD, pourquoi réinventer la roue pour chaque application alors que les DBAL ont justement été développées pour ça.
Si vous n'aimez pas ce commentaire c'est qu'il est ironique.
[^] # Re: contre
Posté par Pooly (site web personnel) . Évalué à 2.
Cependant :
Si le cas est rare, c'est pas très interessant :-)
Et je pense qu'il est quand même utile de tester sur plusieurs des configuration sur laquelle ton appli est censé tournée. Si tu met compatible PostgreSQL et MySQL, et un un bug planqué quelque part ben ç'est mal !
[^] # Re: contre
Posté par Ymage . Évalué à 1.
On ne s'est pas bien compris, je parle bien du même utilisateur de l'application pas du concepteur.
Le concepteur a bien en charge de tester sur plusieurs SGBD, l'utilisateur l'installe lui sur la plate-forme a sa disposition et le cas où un même utilisateur installe une même application sur plusieurs plate-formes est rare et dans le cas où ça arrive, c'est pas vraiment le profile d'utilisateur de pages persos.
Si vous n'aimez pas ce commentaire c'est qu'il est ironique.
[^] # Re: contre
Posté par Éric (site web personnel) . Évalué à 3.
Tu peux retrancher facile 10% pour ADODB, facile 30% pour PEAR::DB, et je suis gentil ... Et plus l'appli est basique avec un machine poussive (coté disque), plus ça va se sentir.
On n'en est pas au niveau des optimisations là, on est vraiment du coté du "oulà c'est lent".
AMHA les avantages compensent les inconvénients, mais ça a un cout, ça c'est certain.
[^] # Re: contre
Posté par Ymage . Évalué à 1.
Maintenant, avec l'arrivée prochaine de PDO, je pense que la lenteur va encore diminuer du fait du codage de la couche en C.
Il me semble par ailleurs qu'ADODB propose déjà une extension PECL.
Si vous n'aimez pas ce commentaire c'est qu'il est ironique.
[^] # Re: contre
Posté par Éric (site web personnel) . Évalué à 3.
> fonctionnels spécfiques des DBAL (gestion des erreurs, transformation de
> ResultSet, etc.)
Non non, je n'exagère pas, et je parle de quand on n'utilise vraiment rien ou presque du DBAL (select classiques)
Pour crédibiliser ce que je dis et donner des chiffres concrets :
MySQL 1.14 -
ADOdbext 1.30 14%
dbx 1.37 20% (index only)
ADOdb 1.45 27%
dbx 1.53 34% (index/assoc/info)
PhpLib 1.60 40%
MDB 1.75 54%
PEAR DB 2.87 152% (fetchInto)
PEAR DB 3.15 176% (fetchRow)
M'base 2.52 296% (numeric cols)
M'base 4.77 318% (assoc cols)
Ce sont des chiffres donnés/faits par les dev d'ADOdb eux-mêmes. On peut donc facilement penser qu'ils ont plutot tendance à gonfler leurs perf qu'à les diminuer. Ca laisse quand même 14% pour l'extension C d'ADOdb, et quasi 30% pour la version PHP que tout le monde utilise. Si on s'intéresse à PEAR::DB ça fait du x2 par rapport au mysql direct.
A mon avis et d'après mon expérience ils exagèrent un peu pour PEAR::DB mais dans l'ensemble l'ordre de grandeur correspond à ce qui est trouvé/publié un peu partout et ce que je vois de coté aussi.
14% ça reste largement acceptable, mais on parle de l'extension C que quasi aucun hébergeur n'a et que beaucoup d'entreprises vont hésiter à mettre puisque non offocielle. 30% à 150% par contre ça devient moins rigolo.
Donc oui, c'est intéressant, mais ça a bien un cout non nul.
> Maintenant, avec l'arrivée prochaine de PDO, je pense que la lenteur va encore
> diminuer du fait du codage de la couche en C.
Sauf que PDO n'est *pas* uen abstraction de base de données. C'est bien dommage d'ailleurs parce que l'idée de base est plutot bonne. Il manque très peu pour pouvoir au moins s'en servir comme DBAL pour des besoins simples, mais ça ne supporte même pas de clause offset/limit, ça ne gère même pas les séquences/autoincrement, etc.
Du coup DBO ça te permet juste de garder les mêmes noms de fonction. Malheureusement c'est vraiment la partie la plus simple et automatique dans un portage. Ce qui prend du temps c'est tout le reste ... que ne fait pas DBO.
PDO l'unique but c'est de n'avoir à apprendre/gérer qu'une seule API unifiée. Par contre l'exploitation de l'API reste dépendante du SGBD (et malheureusement les spécificités des SGBD ne sont pas encore implémentées dans PDO donc la migration vers PDO n'est pas réalisable pour pas mal de gens)
[^] # Re: contre
Posté par Ymage . Évalué à 2.
Cela ralentit la partie accès à la base mais combien de temps l'application passe-t-elle de temps à travailler avec la base ? Entre 10 et 15% pour les plus mal conçues.
Ce qui donne une augmentation globale relativement faible en fin de compte pour le fonctionnement de l'application.
J'ignorais que PDO était aussi peu ambitieux :-(
Je crois que je vais continuer de travailler avec ma DBAL et continuer d'optimiser les reste de l'application avant de songer à la décliner par SGBD pour gagner encore en performance.
Merci pour ces informations.
Si vous n'aimez pas ce commentaire c'est qu'il est ironique.
[^] # Re: contre
Posté par Pooly (site web personnel) . Évalué à 2.
[^] # Re: contre
Posté par Gniarf . Évalué à 6.
sinon, ils proposent de l'hébergement payant, aussi
mysql est supporté, en fait, il faut juste héberger les bases ailleurs, chez soi par exemple. d'ailleurs, cadeau pour les autres :
http://gniarf.nerim.net/phpinfo.php(...)
(pas de gd non plus, par exemple)
[^] # Re: contre
Posté par Louis Nyffenegger . Évalué à 1.
Sinon postgresql c'est quand même autre chose, et je ne vois pas pourquoi l'utilisation de couche d'abstraction ralentirait le tout... en tout cas si c'est bien fait ...
De plus, Postgresql offre énormément de possibilités qui permettent d'accélerer un programme (requêtes imbriquées).
[^] # Re: contre
Posté par Louis Nyffenegger . Évalué à 2.
de peur de dire des bêtises, j'ai été vérifié sur le site de wanadoo :
pour 7,52 euros HT par mois en plus d'un forfait déjà cher:
150 Mo d'espace web
PHP 4 et 30 Mo pour votre base MySQL et phpMyAdmin
Pour ceux qui ne connaissent pas les tarifs en vigueur : 500 Mo pour 30 euros HT par an chez un gros hébergeur...soit 3 fois moins cher pour 4 fois plus d'espace
Donc Nerim est vraiment pas si méchant que ça...
[^] # Re: contre
Posté par Gniarf . Évalué à 1.
par "sans garanties sérieuses de fonctionnement" j'entends qu'en cas de soucis, rétablir la fourniture de ce service n'est pas prioritaire du tout :) contrairement à un hébergeur professionel digne de ce nom.
chez Proxad, c'est un peu pareil, les petits soldats se chargent d'abord d'assurer le service de Online avant celui des pages persos de Free.
dans les faits, cet espace ca sert surtout de petit réservoir à conneries genre video à la con du moment pour ceux qui ne veulent pas se faire pourrir leur connexion. par exemple j'y stocke les images d'un wiki que j'héberge chez moi.
[^] # Re: contre
Posté par jemore . Évalué à 3.
Il y'a meme une option "passé à 1GO" (quelquepart dans l'admin Nerim) . Pour pas un rond de plus.
Mes applis hébergés chez Nerim utilisent toutes ADO donc pas de problème que ce soit MySQL ou Postgre.
Personnellement je prefererais que Nerim installe GD que MySQL...
[^] # Re: contre
Posté par spell (site web personnel) . Évalué à 2.
Pour l'hébergement payant chez Nerim, c'est vrai que je connaissais pas, mais ca concerne soit la location de serveur, soit l'hébergement de serveur. Bref un truc de pro. C'est Hors Sujet donc.
Et pour l'hébergement des bases ailleurs, je trouve l'argument de Nerim éxagéré : Quel hébergeur accepterais que je fasse des requêtes sur sa base de données provenant d'une machine en dehors de son domaine ?
Hum... pas de gd non plus, c'est effectivement un problème... Merci pour l'info.
(Je te rassure j'ai pas l'intention de lancer une pétition pour le support de gd)
[^] # Re: contre
Posté par ookama . Évalué à 3.
* payer un vrai hebergement
* chnager de fournisseur d'acces ?
Nerim propose des choses, le probleme vient jsute que els applis sotn fait uniquement pour une seule BD .
[^] # Re: contre
Posté par spell (site web personnel) . Évalué à 1.
Finalement, je suis d'accord avec toi.
Le problème vient des applis qui ne supporte pas les couches d'abstrations des bases de données.
Dès demain j'envoie des mails auprès des dev des applicaitons qui m'intéressent pour qu'il utilise un moyen d'abstration.
Y'a pas de raison que ce soit que NERIM qui supporte les couts des racourcis de conception des développpeurs.
[^] # Re: contre
Posté par hervé Couvelard . Évalué à 1.
Les dev des applis codent comme ils veulent, avec ce qu'ils veulent. si tu veux une abstraction, fait le toi même. :-)
J'avais lu, de mémoire qu' un code éxécuté dans une fonction est 10 fois plus lent que le code exécuté inliné (pour le php).
Si tu regardes une fonction, dans une fonction, dans une fonction (ce que cela doit à peu près faire avec une abstraction) imagine un peu. J'en suis, pour mes sites, à reprendre mon vieux code de 1999, en le passant à global off, pour remplacer les "" par des '' (pour gagner un peu de performance), réutiliser les même liens aux bases plutôt que de les recréer (je n'utilise pas les p_connect pour alléger la charge de la base de donnée) car même 1 seconde seulement de gagné (tout confondu : accès sql + traitement sql + php + transmissions html) est 1 seconde de gagné pour l'expérience utilisateur.
Pour répondre 'en gros' à ceux qui disent, les codeurs doivent utiliser une abstraction, c'est la même chose que 'les gens doivent utiliser windows' (c'est plus simple et 90% des gens l'ont.)
Je n'utilise pas postgre car c'est plus lourd. Il y a effectivement des choses plus 'sexy', mais j'ai fais le choix du 'rapide', mysql a été conçu pour travailler 'rapidement' sur des grosses bases et des tris importants. De la même manière je n'utilise pas une abstraction, ni une classe pour 'gagner en perf' (même si je dois passer plus de temps à coder [c'est mon métier, coder, pas intégrer des classes].
Je sais que c'est la mode des ide en programmation, des classes toute faites, pré-machées, prête à l'emploi, des pear::tout_ce_qu'on_veut, Cela donne aux gens l'impression de puissance, la capacité à programmer rapidement des trucs qui 'marchent chez moi'. Maintenant, combien de fois rencontre-t-on sur les listes php : 'personne connaitrait un class pour faire des mails ? un mini ftp ?, il va arriver un moment ou 80% des 'programmeurs' vont se retrouver à ne plus connaitre les fonctions de php, mais juste les fonctions des classes.
J'avais besoin sur un site de faire une communication avec jabber dans le sens internet-> mon jabber. La solution de facilité aurait été de prendre la class jabber existante (de l'objet, assez importante pour ce qu'elle fait) mais j'avais besoin de 2 trucs, j'ai donc REECRIT les fonctions dont javais besoin (mais je n'ai pas réinventé la roue, car je n'ai pas fait de l'objet.)
Maintenant je ne dis pas que les class et l'abstraction n'est pas bien. Chaque base de donnée à des spécifités propres, il est dommage de les gommer en utilisant une abstraction, qui, 'par défaut' va utilise le PPCM entre toutes et va ensuite bidouiller pour ajouter un peu de tout à tout : par exemple de l'autoincrement à postgresql. A la fin, plus personne (éxagérons un peu) ne saura ce qui est natif à la base qu'il utilise et ce qui ne l'est pas. et les perfs s'en ressentiront. L'hébergement sera euh... comme free ?
[^] # Re: contre
Posté par Éric (site web personnel) . Évalué à 1.
> fois plus lent que le code exécuté inliné (pour le php).
C'est une stat qui ne veut rien dire. Ca a du être fait en faisant 10000 fois 1+1 dans une boucle et en comparant avec autant d'appels de fonction qui font chacune 1+1.
Dans un cas réel on est très loin de ces chiffres, et non, si tu fais une fonction qui appelle une fonctiton qui appelle une fonction, ton code n'est pas magiquement 1OOx plus lent, heureusement.
> pour remplacer les "" par des '' (pour gagner un peu de performance),
> réutiliser les même liens aux bases plutôt que de les recréer (je
> n'utilise pas les p_connect pour alléger la charge de la base de
> donnée) car même 1 seconde seulement de gagné (tout confondu:
> accès sql + traitement sql + php + transmissions html) est 1 seconde
> de gagné pour l'expérience utilisateur
Ou comment perdre du temps pour rien.
L'histoire du " => ' c'est vrai, mais globalement ça fait gagner des dizièmes de millisecondes au mieux. Si tu gagnes 15s de proc à la fin de la journée tu peux estimé avoir eu une chance extraordinaire. Si tu regardes le temps passé, le smic horaire, tu auras plus vite fait de changer de proc ou rajouter un serveur en load balancing que t'amuser à reprendre tous tes délimiteurs de chaine. Je ne parle meme pas du fait que le " => ' est vrai pour des chaines statiques. Si tu as des remplacements de variables, un "xxx $var xxx" n'est pas plus lent que 'xxx '.$var.' xxx', au contraire. Bref, du temps de perdu pour rien, et autant de possibilités de bugs et régressions si tu fais des erreurs.
L'idée de mutualiser les connect() pour le pas faire plusieurs connexions est encore pire. Mysql réutilise déjà les liens vers la base. Fais 150 mysql_connect() dans le même script avec les mêmes paramètres, PHP n'ouvrira qu'une seule connexion et te renverra toujours le même identifiant. Tu viens donc de repasser tout ton code pour refaire coté utilisateur ce que mysql fait déjà en interne tout aussi bien et probablement plus rapidement, heureux ? Peut être que si ton code était mal organisé tu faisais un peu trop d'accès aux fonctions de connexion là où un attribut de classe aurait été avantageux, mais aller faire la chasse aux connect() n'a aucun sens, ça ne changera rien aux ressources utilisées.
Et tu as quoi comme application pour que ça nécessite d'aller faire des revues de code pour gagner les quelques microsecondes de " => ' ou pour considérer que tu ne peux te permettre de réutiliser des codes existants ?
Heureusement cette mode des performances par les performances est passée. Je ne dis pas qu'il est bon d'ignorer les perfs, ni que les perfs ne servent à personne, mais ce genre de bidouilles qui font gagner 3ms/jour pour 3h de travail ça n'est efficace pour personne, même pour des boites comme yahoo.
[^] # Re: contre
Posté par hervé Couvelard . Évalué à 2.
Si tu veux aller sur ce terrain là, tu as encore plus vite faite de licencier un mec comme toi et externaliser ta prod en roumanie. tu veux un lien, ? nous avons eu un contact aujourd'hui , une boite qui nous a appelé (et nous sommes dans un bled paumé.)
sur www[dot]filingrom[.]com il y a des gens qui t'expliquent que des gens comme toi/moi, on n'en a plus besoin, c'est encore mieux que de prendre un proc plus gros (ca coute pas chère) ou même un disque encore plus gros pour éviter d'avoir à nettoyer tes fichiers temporaires.
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. Ensuite c'est php et pas mysql qui le fait en automatique. Ensuite je te propose de faire un test interessant :
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)
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.)
Est-ce à dire que toutes les certitudes ne sont pas certaines.
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
>C'est une stat qui ne veut rien dire. Ca a du être fait en faisant 10000 fois 1+1
>dans une boucle et en comparant avec autant d'appels de fonction qui font
>chacune 1+1.
>Dans un cas réel on est très loin de ces chiffres, et non, si tu fais une fonction
>qui appelle une fonctiton qui appelle une fonction, ton code n'est pas
>magiquement 1OOx plus lent, heureusement.
Je ne sais pas, comment cela ce fait-il que en c, les compilos (si j'ai tout compris) peuvent inliner (recopier les fonctions à l'intérieur du code pour 'optimiser' en grossissant le binaire ?) si c'était un truc que même des boites comme yahoo ne pouvait économiquement pas utiliser, pourquoi les compilos se prennent le choux avec ?)
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.
Tu considères que des "" à la place des '' c'est des bidouilles ?
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.
Mon expertise du métier est de fournir du code 'sur mesure' pour des applis 'sur mesure' celui qui veut un outils de blogs dotclear, il le télécharge tout seul comme un grand. il y a tellement d'applis/script php écrit avec les pieds ou dans un soucis pédagogique que je ne mettrais pas en prod.
Je ne 'certifie' pas un code que je n'écris pas (pour gagner du temps). Lorsque je mets un code en ligne, je sais qu'il marche pour ce quoi il a été concus et demain, je peux modifier FACILEMENT et sans contrainte ses fonctionnements car je le CONNAIS parfaitement.
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.
Nous proposons du sur mesure, intégré à un processus de travail de l'entreprise, quelque chose que les autres ne peuvent pas faire, car il ne peuvent pas se déplacer dans l'entreprise qui va l'utiliser et faire les 3 liens supplémentaires (inutiles) dont Mme roger aura besoin pour "comprendre" les 3 opérations : elle ne comprends pas que achat/vente/règlement est une MEME opération de flux financier.
Je me souviens de l'article que j'avais écrit en 2001 sur sam mag : de mémoire, "la réponse de la communauté php à un article critque de ZDNET") j'expliquais que php était fort car on travaillait avec des applis taillées à la serpe sur mesure et pas avec des blocs logiciels tout prèts. Il ne serait plus vrai aujourd'hui.
Le choix politique de l'object en php5 pour attirer les dev java ne fait pas l'unanimité au sein du canal historique php, pourquoi d'après toi ?
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.
[^] # Re: contre
Posté par Éric (site web personnel) . É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é ?
[^] # Re: contre
Posté par Gniarf . Évalué à 3.
toi-même chez toi en tant que client Nerim, c'est tout près. les performances n'étaient pas ridicules du tout quand j'avais essayé.
évidement, à ce moment, c'est sûrement nettement plus sexy d'héberger soit-même son Apache et son PHP, c'est à chacun de voir. l'ip fixe et le DNS personnalisé permettent de se prendre pour un pro assez longtemps. ensuite, faut voir ce qu'on veut...
[^] # Re: contre
Posté par moudj . Évalué à 1.
Absolument !
pour mon pc, j'ai eut la même chose, le vendeur m'a fournit "gracieusement" windows et le pack office !!
et l'IP fixe, c'est cadeau aussi ?
et le reverse dns aussi ?
Non, ce sont des services, et facturés... faut arrêter, tout ce que tu as, tu le paies.
[^] # Re: contre
Posté par Gniarf . Évalué à 2.
[^] # Re: contre
Posté par moudj . Évalué à 3.
heu.. cadeau où ?
pour X euros par mois t'as la connexion, l'hébergement, l'ip fixe, le reverse dns, ...
c'est pas cadeau, tu le paies.
alors, effectivement, si t'as l'impression que pour X euros t'as juste la connexion et que tout le reste est cadeau, ok.
moi je vois pas les choses comme ça : je sais qu'en signant le contrat pour X euros par mois j'ai la connexion, l'IP fixe, le reverse....
> c'est vrai que ca doit être l'un des seuls FAIs (moyens ou gros) à proposer ça en france.
effectivement, à part free, ils sont pas nombreux (doux euphémisme)
[^] # Re: contre
Posté par Gniarf . Évalué à 2.
pour info, l'ip fixe c'est dans la limite des stocks disponibles, ca sera proposé tant qu'ils pourront. le reverse DNS, c'est juste une manipulation automatisée depuis longtemps, là le problème ce sont tous les autres FAI qui ne proposent pas d'ip fixe, ce qui rendrait un reverse DNS relativement inutile
[^] # Re: contre
Posté par moudj . Évalué à 2.
mais à 65 euros le méga en non-dégroupé, j'estime que l'ip fixe c'est le minimum...
donc payer plus cher oui, mais on sait pourquoi on paie plus cher :
- les services en plus : ip fixe, reverse, hébergement...
- la qualité de la ligne
c'est à cause du prix élevé de leurs prestations que je considère chaque éléments (ip, reverse) comme étant compris dans le prix.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: contre
Posté par RoX . Évalué à 4.
Ce service est un ajout qui n'apparais en aucun coin du contrat que j'ai signe.
Donc, il est OFFERT sans engagement, puisqu'il n'apparais pas dans ce qui m'est facture.
Que ce choix soit ou non intelligent, n'est pas de mon ressort, ni, AMHA du tien.
92% des ''gens'' utilisent un windows et la majorite des applis tournent sous windos, faudrait-il que Nerim vous montent un hebergement gratuit sous windows en plus ???
Ce FAI a fais ces preuves maintes fois dans ses decisions technologiques, alors venir faire une petition pour exiger un produit tel que mysql ...
Tu as sans doute raison, PostgreSQL est deja largement populaire pour des applis un peu plus importante que .clear, bt, ou spip.
Alors comme repeter n-fois auparavant, rien ne t'empeche de hoster ta DB MySQL sur tes machines (ou ton windows, puisque beaucoup d'applis l'utilisent ...).
Quand a la vocation de Nerim a etre ou pas populaire, j'estime que tu encore tres mal place pour parler en lieu et place du DG de Nerim.
Pour ma part, la plupart de mes confreres ou des gens du milieu technique que je cotoye, connaissent/utilisent et estiment Nerim a sa juste valeur.
Peut-etre parce qu'ils ont deja fait un choix, et que de multiplier les offres necessitent de multiplier les interventions de maintenance, et pusique ce service est offert a titre gracieux, il n'est pas rentable de le faire. (ce n'est qu'une explication que je juge probable).
Des choix de ce genre, ce font par milliers tous les jours dans notre milieu, et les reponses sont a chaquue fois les memes ...
Il a raison d'en parler, mais pourquoi ne pas passer sur IRC et en faire la demande a Raphit ?
Ca serais plus simple, moins contraignant et il aurais eu une reponse argumentee en direct.
Non, il est sur que faire du bruit pour une petition est tellement plus simple et tellement plus correct et poli.
C'est, AMHA, juste un manque flagrant d'education et de bonne conduite.
# Suggestion de petitions
Posté par Ymage . Évalué à 6.
De mon côté, je vais lancer une pétition pour que les pétitions nombrilistes de ce genre soient interdites. :-p
Le prend pas mal, mais franchement, ton argumentation est parfaitement à côté de la plaque.
Le FAI Nérim a fait un choix technique pour son infrastructure, et tu n'es nullement obligé de choisir ce FAI.
Et si tu l'as choisi avant la mise à disposition d'un hébergement, tu peux déjà être satisfait qu'il te mette un hébergement parfaitement fonctionnel à disposition.
Si vous n'aimez pas ce commentaire c'est qu'il est ironique.
[^] # Re: Suggestion de petitions
Posté par spell (site web personnel) . Évalué à 5.
Pour lancer une pétition contre les nombrilistes, tu as le droit aussi, et tu pourrais même lancer une pétition contre les gens qui pensent pas comme toi aussi.
Plus sérieusement, le but est de savoir si je suis à coté de la plaque ou si l'offre de Nerim est à coté de la plaque, car je me suis reposé la question plusieurs fois.
C'est faire avancer les choses que de se remettre en question; Tous les gens qui essayent de faire avancer les choses sont certainement un peu nombrilistes, car ils ont osé pensé à leur besoin.
Soit persuadé que si je ne pensais pas que MYSQL pourrait intéresser d'autres gens, je n'aurais pas lancé de pétition.
[^] # Re: Suggestion de petitions
Posté par Gniarf . Évalué à 1.
maintenant l'argument historique "ça ne sert pas à grand chose de proposer d'héberger des bases mysql, ca sera en rideau dès qu'une usine à gaz à la phpnuke sera utilisée sérieusement" tient malheureusement la route. s'amuser à héberger soi-même quelques unes de ces bouses peut aider à s'en convaincre.
[^] # Re: Suggestion de petitions
Posté par ookama . Évalué à 2.
il offre quand meme PHP, PostgreSQL, 1Go
tu ne dois t'en prendre qu'au dévelopeur de logiciel.
[^] # Re: Suggestion de petitions
Posté par Gniarf . Évalué à 2.
tu te trompes visiblement de personne, pour le reste
# L'inverse...
Posté par Médéric RIBREUX (site web personnel) . Évalué à 7.
dans mon cas, je ferais bien une pétition pour que Free propose PostgreSQL comme DB en lieu et place de MySQL.
[^] # Re: L'inverse...
Posté par spell (site web personnel) . Évalué à 2.
Quelles applis voudrais-tu installer ?
[^] # Re: L'inverse...
Posté par dab . Évalué à 3.
Bref, PostgreSQL, abstraction Power.
Et puis MySQL power, enfin bref, choix power.
[^] # Re: L'inverse...
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 2.
Je plussoie fortement, et je demande l'activation de PL/pgSQL dans la foulée...
# plus cher
Posté par Colin Leroy (site web personnel) . Évalué à 3.
NERIM est déjà plus cher que ses concurrents. Et les autres hébergeurs s'en sortent bien. Au pire NERIM n'a qu'a proposer cette base en option.
Nerim n'est pas un hébergeur mais un FAI. L'hébergement est un à-côté. De plus, il convient de rappeller que si nerim est plus cher, c'est parce qu'ils ne vendent pas à perte, d'une part, et aussi pour certains détails comme la hotline sur laquelle tu trouves un technicien qui comprend "traceroute" et "timeout waiting for PADO packets" en une minute ;-)
Si Nerim proposait une base MySQL, ça monopoliserait effectivement des ressources, et le prix devrait augmenter. Pas sûr que ça m'intéresse, perso.
[^] # Re: plus cher
Posté par Dinofly (site web personnel) . Évalué à 1.
Ah ? Ca a changé alors :-)
Il y a 5 ou 6 ans, quand un ami leur avait demandé s'ils proposaient une IP fixe on lui a répondu sur un ton très fier que non seulement l'IP était fixe, mais qu'en plus (comble du bonheur) elle était dynamique !
[^] # Re: plus cher
Posté par Donk . Évalué à 1.
[^] # Re: plus cher
Posté par barca . Évalué à 1.
C'est ce qu'on apelle le DHCP fixe, d'où des adresses IP dynamiques (DHCP) et fixe en même temps.
[^] # Re: plus cher
Posté par Dinofly (site web personnel) . Évalué à 1.
Enfin de toutes façons la conseillère de chez Nerim ne savait visiblement pas de quoi elle parlait ("IP fixe ? C'est le chien d'Obélix ?") et semblait penser que tout ce qui est "dynamique" c'est vachement bien.
[^] # Re: plus cher
Posté par Colin Leroy (site web personnel) . Évalué à 4.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.