D'après l'auteur et en résumé, PHP doit mourir, car il est totalement incapable de fonctionner de manière asynchrone correctement.
Ainsi, l'écriture d'un démon fiable en PHP serait une mission quasi impossible, voire suicidaire, car le langage serait totalement incapable de gérer sa mémoire de manière correcte.
Il justifie cela par le fait que le Zend Engine n'est pas destiné à être exécuté en permanence et que cela aurait conduit ses concepteurs à négliger la gestion des éventuelles fuites de mémoire générées par leur code.
J’en rigole encore.
J'ai écrit mon premier démon en PHP quelque part entre les années 2000 et 2005, dans le but de superviser certains traitements dans un environnement de production.
Et par la suite, j'en ai écrit bien d'autres pour remplir des tâches diverses et variées aussi bien dans un cadre professionnel que personnel.
Ainsi, en 2005, j'en ai par exemple conçu un certain nombre pour gérer le comportement de wmii, le gestionnaire de fenêtre que j'utilisais à l'époque sur mon ordinateur portable sous FreeBSD.
Dans un tel contexte, mes démons en PHP étaient exécutés en permanence pendant plusieurs semaines, car je redémarre très peu mes ordinateurs.
Et dans tous les cas, je n'ai jamais constaté la moindre fuite de mémoire.
Quand je vous dis que j’en rigole encore, ce n’est pas pour rien…
D'autant que je ne suis pas le seul à m'amuser à ce genre d'exercice.
Amaury Bouchard est aussi un concepteur de démon en PHP, à tel point qu'il a même donné une excellente conférence sur le sujet lors du dernier Forum PHP.
Et Amaury ne fait pas particulièrement dans la dentelle, puisqu'il se sert de démons en PHP pour synchroniser un système de fichier distribué dans un cadre professionnel.
Et à ma connaissance, il n'a jamais rencontré le moindre problème de fuite de mémoire dans ce contexte.
Je sais également qu'Ivan Enderlin, le créateur de l'ensemble de bibliothèques pour PHP connu sous le nom de Hoa, s'est aussi beaucoup amusé à faire ce genre de choses.
Et toujours à ma connaissance, PHP ne lui a jamais posé le moindre problème en ce qui concerne la gestion de sa mémoire, alors qu'il est vraiment très fort pour pousser le langage dans ses derniers retranchements.
De plus, si les références circulaires pouvaient effectivement être un problème par le passé, ce n'est plus le cas depuis le 22 juillet 2010, date de sortie de PHP 5.3.3.
PHP, n’en déplaise à ceux qui souhaitent sa mort, est en effet un langage encore bien vivant.
Il est en effet activement développé et ses développeurs sont tout à fait conscients, bien plus que vous ou moi, de ses forces et de ses faiblesses.
Ils font donc tout ce qu'il faut pour que PHP s'améliore et devienne plus efficace et performant, j'en veux pour preuve le gain de 30 % apporté par PHP 5.4 à la fois en terme de vitesse d'exécution et de consommation mémoire.
J'ajoute que PHP-FPM est également un excellent moyen de faire réaliser des tâches asynchrones au langage.
De plus, PHP permet également de déléguer très facilement ce genre de tâche à des outils spécifiquement conçu pour répondre à cette problématique, comme par exemple gearman.
Certes, cela demande un hébergement disposant des extensions adéquates, mais quand on commence à avoir ce genre de besoin, on a en général à sa disposition une infrastructure plus sérieuse qu'un serveur mutualisé chez un hébergeur à bas prix.
En conséquence, si la légende urbaine colportait à une époque le fait que PHP n'était pas le langage adéquat pour faire de l'asynchrone ou écrire un démon, ce n'est certainement plus le cas aujourd'hui, si tant est que cela ne l'ait pas été un jour, et évidemment à la condition de coder correctement.
À bon entendeur…
16 réactions
1 De Laurentj - 05/04/2013, 15:09
Il y a aussi le projet Photon, qui, s'y j'ai bien compris reste lui aussi en mémoire en permanence http://www.photon-project.com/
2 De mageekguy - 05/04/2013, 15:31
@Laurentj : Exact, avec en plus du øMQ derrière pour s'amuser encore plus…
3 De Amaury Bouchard - 05/04/2013, 15:41
Tout à fait d'accord avec toi, évidemment !
4 De mnapoli - 05/04/2013, 15:50
Je tiens à dire que je suis tout à fait d'accord avec toi, j'ai déjà fait tourner des démons en vanilla PHP ou appuyé sur Beanstalkd ou Gearman et ça marche très bien.
Je dirais même que 95% des possibles problèmes sont anticipés avec Supervisor qui se chargera de relancer notre démo immédiatement au cas où celui-ci se crashe. Et je n'ai jamais vu un démon crasher pour une raison qui n'était pas lié à un bug de mon code.
5 De Victor - 05/04/2013, 16:42
C'est pas la peine de s'énerver comme ça !
J'ai pas du tout la même lecture de l'article "PHP is meant to die" que toi et pour une fois je trouve que c'est un article plutôt bien argumenté.
C'est plutôt ta réponse qui manque d'arguments, tu parles beaucoup de démons mais pas de l'asynchrone dans le sens où l'entend l'auteur. Je pense qu'il parle de la prog event-driven comme ReactPHP (http://reactphp.org/) qui existent dans beaucoup d'autres langagues depuis bien longtemps (et même depuis bien avant Node qui est très hype ajd'hui).
Il me semble que l'auteur veut dire que PHP n'est pas toujours le meilleur outil (cf la prez "Don't use a screw when you need a nail" - http://www.slideshare.net/skoop/don...) et c'est la vraie vérité.
L'auteur reconnaît aussi que la situation c'est ameliorée: "Maybe there’s people that think that a more services-oriented architecture may help to overcome PHP’s limitations. Maybe there’s people that can argue that PHP 5.4 or PHP 5.5 are a lot better, and that the language is slowly improving.".
En conclusion je pense qu'il y a pas mal de choses a retirer de cet article pour l'évolution de PHP et qu'il est aussi vrai que si PHP ne sait pas s'adapter rapidement, il ne sera simplement plus dans la course pour les nouveaux usages du web et il va forcément perdre en vitesse.
6 De Guillaume Dievart - 05/04/2013, 18:26
Pour ma part je développe depuis peu des démons PHP pour de la téléphonie, et je ne peux que confirmer que ça tourne très bien, et pendant plusieurs mois sans memleak
7 De Paul - 08/04/2013, 09:16
J'ai plusieurs démons qui tourne et je n'utilise que les fonctions standard et je n'ai jamais constaté de fuite mémoire.
Par contre, ce qui est beaucoup plus bloquant pour faire des demons c'est l'inexistence des "thread". Et même si souvent lancer un autre processus permet de palier à ce problème, partager une ressource (connection BD) et souvent un enorme casse tête voir impossible.
J'espère qu'un jour PHP aura une vrai gestion des exceptions comme python/java et un vrai système de "thread".
J'y crois
8 De Pascal MARTIN - 08/04/2013, 13:40
@Paul pour ce qui est des threads, tu as l'extension pthreads qui pourrait répondre.
Cf https://github.com/krakjoe/pthreads et http://fr2.php.net/pthreads
Par contre, j'admet, ce n'est pas fourni "de base" (et ça ne le sera probablement jamais : ce n'est pas "la logique" de PHP, et ne répond à un besoin que seuls peu d'utilisateurs ont) ; et ça demande de recompiler PHP en activant ZTS.
9 De Eric - 08/04/2013, 16:06
@mageekguy : Humm ceci dit Photon n'a pas l'air ultra maintenu non plus
10 De Eric - 08/04/2013, 16:37
@Pascal MARTIN : Ce qui est ennuyeux avec les threads c'est que la version ZTS est assez peu testée et pas du tout prioritaire dans la tête des dev php. On est bien dans la logique une requête/une réponse.
Mais théoriquement le "event driven" permet justement d'éviter d'utiliser les threads. Les retours des autres langages étant que finalement ils sont complexes à mettre en oeuvre, complexe à debugger et génèrent des cas impossible à reproduire (non testables donc).
11 De Pascal MARTIN - 08/04/2013, 18:38
@Eric de ce que je peux lire sur internals@, je confirme que la version ZTS n'est pas considérée comme "importante", effectivement (historiquement, elle servait surtout sous windows, qui n'est pas une cible prioritaire dans l'esprit de beaucoup ; et même sous windows, ce n'est plus vraiment "la" solution).
Des cas impossibles à reproduire, je veux bien le croire ; déjà en multi-processus (donc sans mémoire partagée), avec jouant avec du cache, des fichiers, et de la base de données, on arrive des fois à s’emmêler les pinceaux...
Mais il doit bien y avoir quelques cas bien spécifiques où jouer avec des threads peut apporter un certain gain (ne serait-ce que niveau perfs, pour jouer des traitements en arrière-plan ou en parallèle) -- à condition de ne pas en abuser, et de savoir ce qu'on fait, bien entendu.
12 De mageekguy - 08/04/2013, 21:59
@Pascal MARTIN : Le plus gros problème posé par la parallélisation, qu'elle passe par des threads ou du fork, c'est qu'il y a finalement assez peu d'algorithme véritablement parallélisable sans problème.
13 De Ludo - 10/04/2013, 01:58
"D'après l'auteur et en résumé, PHP doit mourir", si je ne m'abuse, c'est un jeu de mot que l'auteur reconnait faire lui même dans sa conclusion.
Dans le sens le process php doit s'arrêter: genre die(), le titre est racoleur et l'auteur le souligne, mais il se précise à chaque fois qu'il ne souhaite pas la mort de php.
14 De krakjoe - 12/04/2013, 09:58
That article reads like a baker describing how to build a skyscraper. The author is clueless. The author clearly has no real knowledge of memory management or garbage collection, or any of the other things he has drawn ridiculous conclusions about.
People love to hate on PHP, the number of websites relying on PHP show very clearly that none of these concerns are genuine. PHP cannot be everything to everyone, but it does manage to be everything to about three quarters of the internet, so you have to wonder, what is more likely, that three quarters of the internet are struggling to run their websites, or that the tiny fraction of users complaining about problems which they are not even qualified to talk about are completely and utterly wrong. Programming should give you that most important human ability - being logical, use it, use it all the time, use it especially when faced with nonsense.
15 De exfromtheleft - 14/04/2013, 19:06
@Victor : puis je te poser une question assez simple, connais tu un langage qui est toujours et en toute circonstance le meilleur outil?
16 De Jérôme - 11/10/2013, 15:56
Il y a quand même une chose qui m'échappe... vous vous êtes investis à ce point dans PHP que la seule penser d'apprendre autre chose de plus moderne, mieux pensé, plus efficace vous terrifie ?
Pour moi ça ressemble quand même beaucoup à une mentalité à la : "surtout ne pas essayer quelque-chose d'autre, ça pourrait me plaire".
C'est désolant de voir autant de stagnation. Les gens ne critiquent pas (tous) PHP par plaisir, mais parce qu'ils ne comprennent pas que vous soyez aveugles à ce point. Il ne faut pas voir les attaques comme une critique personnelle mais bel et bien comme une expression d'incompréhension.
Moi perso, je me moque que vous dédiez vos vies au PHP, limite ça m'arrange, ça permet de filtrer rapidement les C.V à l'entrée : "tiens, il fait que du PHP, ça doit être un sacré rétrograde". Mais si vous tenez à votre carrière, mettez vos égos de coté et essayez au moins sérieusement d'autres technos au lieu d'essayer toujours et encore de coller des rustines sur un langage dont les fondations même sont bancales.
Non, PHP ne va pas mourir demain, il va toujours exister, comme le COBOL.