@jpfox @nlavielle @prunus @Keltounet Ce n’est pas qu’au niveau du langage. C’est un tout surtout.
Le fait de ne pas avoir de serveur d’application est rédhibitoire pour espérer en faire quelque chose de propre.
@jpfox @nlavielle @prunus @Keltounet Ça repose sur des tricks abominables pour arriver à faire du templating ou du layout correctement.
Ce que du RoR/Django/Java intègre nativement via le serveur d’appli et la possibilité de dissocier le fichier de l’URL appelé…
@jpfox @nlavielle @prunus @Keltounet PHP est aussi rarement auto-porteur, tu as besoin de bidouilles côté httpd pour t’en sortir, par exemple via du rewriting tout moche…
@aeris @Keltounet @prunus @nlavielle @jpfox Le rewriting ça se fait plus vraiment, maintenant en général, tu as un seul point d'entrée et un routeur.
@Naouak @jpfox @nlavielle @prunus @Keltounet Wé, et donc t’as refait en applicatif (et sans serveur d’appli, donc perf----) un truc supposé être géré par ton serveur d’appli…
@aeris @Keltounet @prunus @nlavielle @jpfox Si tu choisis PHP pour les perfs, tu t'es trompé de profession en même temps.
Le bon point de PHP c'est que tu fais avec pas grand chose des trucs rapidement. C'est un bon truc pour du prototypage web.
@Naouak @jpfox @nlavielle @prunus @Keltounet Je fais *VACHEMENT* plus rapidement du prototypage en RoR qu’en PHP justement.
Parce que tout est inclus de base pour ne pas avoir à s’emmerder à réimplémenter MVC/templating/connection à la DB/ORM, etc
@aeris @Keltounet @prunus @nlavielle @jpfox Templating ? PHP est language de template FFS. MVC ? Tu fais du prototypage ou tu fais un produit fini ? Connection à la db ? PDO gere ça correctement dans le use case serveur web. ORM ? Pas besoin pour un prototypage et ce sont souvent de la branlette qui sert qu'à pourrir les perfs parce qu'on pourrait passer de postgre à oracle un jour.
@Naouak @jpfox @nlavielle @prunus @Keltounet PDO ne gère *pas* les pools de connexion ! À chaque requête, c’est parsing des modèles et connexion à la DB !!!
@aeris putain mais c'est pas à PDO de gérer des pool merde ! Tu te trompes de couche. C'est à la DB de se démerder avec son architecture putain ! @Naouak @jpfox @nlavielle @Keltounet
@prunus @Naouak @jpfox @nlavielle @Keltounet MySQL ou PostgreSQL ne pourront *jamais* faire de pooling. Ce n’est pas leur boulot du tout.
@prunus @Naouak @jpfox @nlavielle @Keltounet Et en pratique, ils ne peuvent de toute façon pas savoir quelle appli est en train de se connecter dessus. Au mieux ça serait un pool par user/db, mais c’est pas suffisant du coup pour éventuellement discriminer par application.
@aeris ok tu veux pas comprendre. Reste à dire des conneries et à t'en prendre plein la gueule. On ne peut vraisemblablement pas discuter. @Naouak @jpfox @nlavielle @Keltounet
@prunus @Naouak @jpfox @nlavielle @Keltounet Je ne suis pas le seul à ne pas comprendre alors 😂
Un pool de connexion au niveau de la db, juste je ne vois même pas comment ça peut fonctionner…
@prunus @Naouak @jpfox @nlavielle @Keltounet Et même si c’était possible, ça serait de toute façon plus coûteux d’avoir à se reconnecter à la base (sur le pool donc) à chaque requête qu’à stocker en mémoire la connexion ouverte juste la requête d’avant 😂
@aeris Tu peux avoir des connexions persistantes en PHP (et qui sont donc réutiliser à chaque requête).
@zoddo Ptête parce que ça n’aurait jamais du finir sur de la prod ? 🤔 😂