mageekblog - Mot-clé - PCNTL - CommentairesLe blog personnel de Frédéric Hardy. Au menu, PHP, agilité, FreeBSD, cuisine et photographies.2021-12-02T08:20:54+01:00Frédéric Hardyurn:md5:26874ca5b8cd4cac8d08b0e68e64f63aDotclearDémon en PHP : une solution pertinente ? - funkyprojecturn:md5:f27456af582ac32f48200f18b45961862011-05-10T07:40:47+02:002011-05-10T14:14:12+02:00funkyproject<p>@mageekguy: Il n'y a pas pour le moment pas d'intérêt à modifier la solution, mais je suis toujours à la recherche d'amélioration potentiel dans tout ce que je fais.<br />
Remise en cause permanente, peut être une déformation d'agiliste <img src="/themes/default/smilies/wink.png" alt=";-)" class="smiley" /></p>
<p>Merci de ta réponse en tout cas. Je me rend compte en écrivant que je cherche à pallier au multi thread. J'ai besoin que la tache soit exécutée quasiment en même temps que le chargement en queue, il s'agit juste pour moi de délivrer la page html plus rapidement.</p>Démon en PHP : une solution pertinente ? - mageekguyurn:md5:c737d91fb33c376c477908d22a528bb92011-05-09T21:35:39+02:002011-05-09T20:40:55+02:00mageekguy<p>@<a href="http://blog.mageekbox.net/?post/2011/05/05/D%C3%A9mon-en-PHP-%3A-une-solution-pertinente#c2974" rel="nofollow">funkyproject</a> : Si tu dois interroger activemq à intervalle régulier avec une granularité supérieure ou égale à la minute, un script en cron peut être une alternative.</p>
<p>Si tu dois interroger activemq en fonction d'un événement réseau, comme l'ouverture d'une connexion sur un port précis, tu peux utiliser la solution d'Amaury, à savoir un script démonisé par inetd/xinitd. </p>
<p>Mais je pense qu'il faut te demander l'intérêt de modifier ta solution, si elle est fonctionnelle et qu'il y a dans ta société les compétences et les connaissances nécessaire à sa maintenance.</p>Démon en PHP : une solution pertinente ? - funkyprojecturn:md5:341b7a9d8ff09c17b09bd8e6387cdbf22011-05-09T11:25:38+02:002011-05-09T20:40:55+02:00funkyproject<p>bonjour, merci pour l'article.</p>
<p>J'utilise depuis un moment, en remplacement de cron, un script shell qui boucle sur un php -f ...<br />
avec une commande WAIT du processus, pour interroger activemq. L'avantage est d'avoir une queue multiplateforme , un processus php unique , un limit_memory qui fait son travaille. C'est stable en production mais y a t'il une alternative à ma solution ?</p>Démon en PHP : une solution pertinente ? - loïc m.urn:md5:a635145866420d63ca6a1528a665f93a2011-05-06T17:10:18+02:002011-05-06T16:45:33+02:00loïc m.<p>@paul : deamon php vs. cron qui exécute une tâche php<br />
où le deamon est plus intéressant que la tâche cron</p>Démon en PHP : une solution pertinente ? - Paulurn:md5:8ceb4ae3669e003507102f91e3d9ce9a2011-05-06T13:18:06+02:002011-05-06T12:32:15+02:00Paul<p>@Loïc m, tu cherches<br />
1°) un exemple ou un démon est une meilleure solution à cron<br />
ou alors<br />
2°) un exemple ou un démon en __PHP__ est une meilleure solution à cron</p>Démon en PHP : une solution pertinente ? - Bds023urn:md5:e80c5803c3efe41c6d98f879eef7a52a2011-05-06T12:20:29+02:002011-05-06T12:32:15+02:00Bds023<p>@mageekguy</p>
<p>Pour avoir étudier récemment un problème de fuite mémoire PHP, j'ai découvert que ce bug(<a href="http://bugs.php.net/bug.php?id=33487" title="http://bugs.php.net/bug.php?id=33487" rel="nofollow">http://bugs.php.net/bug.php?id=3348...</a>) est toujours présent en PHP et que le GC ne le corrige pas.</p>
<p>Par conséquent, je ne suis pas partisan des demons PHP. Ce n'est pas le langage adéquat. Par contre, il est tout à fait possible de faire en démon avec un langage approprié et qui appel des scripts PHP.</p>Démon en PHP : une solution pertinente ? - Yannick K.urn:md5:fb03ff6ba75c3feb34836e2235e53ce52011-05-06T11:13:48+02:002011-05-06T10:21:01+02:00Yannick K.<p>Perso j'ai toujours utiliser schtasks (<a href="http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/schtasks.mspx?mfr=true" title="http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/schtasks.mspx?mfr=true" rel="nofollow">http://www.microsoft.com/resources/...</a>) comme alternative à crontab sous windows, je n'ai aucun soucis jusque là. Cependant je suis bien d'accord que l'utilisation de PHP pour l'écriture des démons n'est pas top comme solution. Matthieu Robin, le script était distant ?</p>Démon en PHP : une solution pertinente ? - Amauryurn:md5:1253b69458d4ed678622532e5f55aa2a2011-05-06T10:51:30+02:002011-05-06T10:44:42+02:00Amaury<blockquote><p>En ce qui concerne inetd/xinetd, cette solution ne permet pas la mise en œuvre d'un démon, mais d'un script, un démon ne devant pas utiliser les entrées/sorties standards.</p>
</blockquote>
<p>Justement, inetd/xinetd permet de "démonifier" un script. Quand tu dis qu'un démon ne doit pas utiliser ses entrées-sorties standard, tu veux parler des démons autonomes classiques, j'imagine. Cela n'a plus aucun sens avec inetd, dont le principe fondamental est d'encapsuler les programmes, d'être le démon à leur place, et de communiquer avec eux en utilisant les descripteurs standards.</p>
<p>Il est bien plus facile et rapide de développer un simple script qui utilise ses entrées-sorties standard que de coder un démon complet (socket, accept, fork, gestion des signaux). Au final, on obtient bien un démon qui écoute sur le port voulu et qui traite les connexions entrantes.</p>
<p>Évidemment, il faut que le script en question soit développé spécifiquement, avec cet usage en tête. Il ne faut pas prendre n'importe quel script CLI et le mettre dans inetd sans plus de réflexion.</p>
<p>Mais, sincèrement, pour la plupart des «petits démons», ceux qui servent pour des usages non critiques ou qui n'ont pas de trop grosses charges à supporter, c'est une solution très efficace.</p>Démon en PHP : une solution pertinente ? - Mathieu ROBINurn:md5:b49decf8e076a4329cd8826d3b8bbbe02011-05-06T09:54:54+02:002011-05-06T08:59:44+02:00Mathieu ROBIN<p>Sous Windows (pour avoir déjà eu à le faire - sous la contrainte, j'étais un pauvre stagiaire), il y a une solution usine à gaz :<br />
Tâches planifiées Windows appelant l'exécution d'un script batch lui même faisant appel à une version windows de wget qui lui appellera les scripts php. 100% de chances que ça se plante au bout de quelques semaines pour une raison x ou y. Avec l'instabilité naturelle de windows en première ligne.<br />
Pour le coup par contre, je n'ai jamais eu à faire de démon, ayant toujours pu coder une alternative avec cron. Et que c'est bon d'avoir cron sous Linux parce que bordel, qu'est-ce que le système de tâches planifiées sous windows est vraiment moisi...</p>Démon en PHP : une solution pertinente ? - loïc m.urn:md5:52aebb6d334a80c453952b32e2729adf2011-05-06T09:53:58+02:002011-05-06T08:59:44+02:00loïc m.<p>pour corriger mon post précédent :</p>
<p>"travaillant dans le domaine de la télésurveillance, nous utilisons les tâches cron pour gérer des actions asynchrones qui peuvent attendre 1 minute au maximum avant d'être exécutées"</p>
<p>merci pour les exemples</p>Démon en PHP : une solution pertinente ? - mageekguyurn:md5:d1055674076dedf1637caa5a0abbeac82011-05-06T09:46:53+02:002011-05-06T08:59:44+02:00mageekguy<p>@<a href="http://blog.mageekbox.net/?post/2011/05/05/D%C3%A9mon-en-PHP-%3A-une-solution-pertinente#c2963" rel="nofollow">Amaury</a> : Le billet a été rédigé en fonction des questions qui m'ont été posé, à savoir ce qui est le mieux entre un script en cron et un démon, et j'ai donc rédigé mon billet en conséquence, sans évoquer d'autres alternatives.</p>
<p>En ce qui concerne <code>inetd</code>/<code>xinetd</code>, cette solution ne permet pas la mise en œuvre d'un démon, mais d'un script, un démon ne devant pas utiliser les entrées/sorties standards.</p>
<p>La philosophie de ces outils est donc similaire à celle de <code>cron</code>, si ce n'est que le déclenchement sera alors événementiel et que cela pose effectivement des problèmes au niveau de la montée en charge et de la consommation des ressources.</p>
<p>Concernant le lock, je ne l'ai pas précisé vu que mon billet est essentiellement fonctionnel, et non technique, et de plus, cela me semblait être évident.</p>
<p>D'ailleurs, tant que nous sommes dans la technique, je recommande de lancer un démon en PHP avec un interpréteur PHP compilé avec uniquement les fonctionnalités indispensables, ainsi qu'un php.ini spécifique.</p>Démon en PHP : une solution pertinente ? - Amauryurn:md5:75d43ff35d6bcbab62b683957ddb45a82011-05-06T09:42:38+02:002011-05-06T08:59:44+02:00Amaury<p>Un article presque entier à confronter les démons et la crontab... C'est un peu comme comparer HTTP et FTP : ça peut éventuellement être utilisé pour la même chose, mais l'écrasante majorité des utilisations est différente.</p>
<p>On écrit un démon pour réagir à des évènements, qui sont la plupart du temps des connexions entrantes. Faire un démon pour exécuter des tâches récurrentes, c'est inutile, il vaut effectivement mieux utiliser la crontab.</p>
<p>Sinon, parler des démons sans même évoquer inetd/xinetd, c'est fort. Tous les avantages que tu décris dans l'utilisation de la crontab (instanciation unique, donc fuites mémoire limitées, relecture du fichier de conf, ...) peuvent être mis en œuvre dans la création d'un démon en le basant sur inetd/xinetd. C'est une solution permettant d'écrire un démon très rapidement, car c'est alors juste un script CLI qui lit sur son entrée standard et qui écrit sur sa sortie standard. C'est juste limité en montée en charge, puisque chaque connexion entrante va instancier le chargement de l'interpréteur PHP complet. Cela reste très efficace pour la plupart des usages.</p>
<p>Autre chose, utiliser la crontab pour effectuer des tâches récurrentes impose souvent de mettre en place une solution de lock, pour éviter d'avoir plusieurs exécutions simultanées du même script. C'est une chose souvent oubliée par les développeurs qui codent leurs premiers scripts destinés à la crontab, ce qui génère fréquemment des bugs difficiles à reproduire.</p>Démon en PHP : une solution pertinente ? - mageekguyurn:md5:c432e3004b213d5e9c4844cf91c900282011-05-06T09:02:57+02:002011-05-06T08:05:40+02:00mageekguy<p>@<a href="http://blog.mageekbox.net/?post/2011/05/05/D%C3%A9mon-en-PHP-%3A-une-solution-pertinente#c2955" rel="nofollow">loïc m.</a> :Votre commentaire étant incomplet, j'ai du mal à comprendre votre demande, mais sans trop y réfléchir, je vois assez peu de cas ou une réactivité proche du temps réel serait nécessaire, à part justement dans un contexte temps réel, comme de la synchronisation de données ou de la surveillance/monitoring, </p>Démon en PHP : une solution pertinente ? - mageekguyurn:md5:9a609df4066bc8e35d6e68c01fc20f022011-05-06T08:59:24+02:002011-05-06T08:02:28+02:00mageekguy<p>@<a href="http://blog.mageekbox.net/?post/2011/05/05/D%C3%A9mon-en-PHP-%3A-une-solution-pertinente#c2959" rel="nofollow">Paul</a> : Je répète : PHP en lui-même n'a pas de fuite de mémoire significative en utilisation conventionnelle.</p>
<p>J'ai des démons qui tournent avec 4 Mo depuis très longtemps, et ça ne bouge absolument pas.</p>
<p>S'il y en a, elles proviennent dans la grande majorité des cas d'extension tierce, comme Xdebug, par exemple (oui, c'est assez paradoxale).</p>Démon en PHP : une solution pertinente ? - mageekguyurn:md5:552c47bb13b3fdbf4c76fe561016e8dd2011-05-06T08:57:32+02:002011-05-06T08:11:04+02:00mageekguy<p>@<a href="http://blog.mageekbox.net/?post/2011/05/05/D%C3%A9mon-en-PHP-%3A-une-solution-pertinente#c2958" rel="nofollow">Ivan Enderlin</a> : Tmux qui plante ??? Nous ne devons pas parler de la même chose.</p>
<p>Sinon, c'est une très mauvaise idée de lancer un démon autrement que par la CLI, à moins éventuellement de passer par un pcntl_exec() pour remplacer le code du fork par celui du script de ton choix, mais je ne suis même pas certain de cela, car j'ignore comment se comporte PHP vis à vis des descripteurs ouverts et des ressources consommées dans ce cas.</p>
<p>C'est à tester.</p>Démon en PHP : une solution pertinente ? - Paulurn:md5:739b6f6864e5f1d4ab53c9b42c3197472011-05-06T07:10:23+02:002011-05-06T08:02:37+02:00Paul<p>C'est quand même dommage, qu'encore aujourd'hui PHP puisse encore avoir des fuites mémoires.<br />
Certes pour la programmation de page web c'est pas grave, vu que généralement le temps d'execution d'un script est très rapide, mais ca fait pas très "pro".</p>
<p>En tout cas merci pour le billet.</p>Démon en PHP : une solution pertinente ? - Ivan Enderlinurn:md5:cb1cc804e12da6536d0c284008f52c6f2011-05-06T07:03:38+02:002011-05-06T07:59:31+02:00Ivan Enderlin<p>Hey :-),</p>
<p>La mère ou la mer à boire ?<br />
Tmux n'est pas assez stable contrairement à screen. Pour simplement lancer un script, screen est amplement suffisant.</p>
<p>Je réfléchis depuis un moment à faire des démons avec des sockets mais ce n'est pas simple. FastCGI fonctionnant uniquement en TCP, ce n'est pas facile de le désynchroniser. Une autre piste à suivre ?</p>Démon en PHP : une solution pertinente ? - Francisurn:md5:cba1cf1a8bead907bc6064d6a281e7272011-05-06T00:58:49+02:002011-05-06T07:59:08+02:00Francis<p>Si on parle d'asynchrone et de déléguer une partie de l'intelligence sur les pages web pour ne pas altérer leur déroulement, je pense que gearman est un très bon outil.</p>
<p><a href="http://gearman.org/" title="http://gearman.org/" rel="nofollow">http://gearman.org/</a></p>Démon en PHP : une solution pertinente ? - loïc m.urn:md5:665e818598225f29584b5dca148abbec2011-05-06T00:53:48+02:002011-05-06T08:08:15+02:00loïc m.<p>Auriez-vous des exemple où il est primordial qu'un script s’exécute immédiatement et qui justifierait l'utilisation des deamon PHP ?</p>
<p>travaillant dans le domaine de la télésurveillance, nous utilisons les tâches cron pour gérer des actions asynchrones qui peuvent attendre 'au maximum avant d'être exécutées</p>Démon en PHP : une solution pertinente ? - mageekguyurn:md5:3edbf5340f46592abbce21b62a2a31e72011-05-06T00:37:02+02:002011-05-05T23:43:58+02:00mageekguy<p>@<a href="http://blog.mageekbox.net/?post/2011/05/05/D%C3%A9mon-en-PHP-%3A-une-solution-pertinente#c2953" rel="nofollow">desfrenes</a> : <troll>Tu devrais utiliser tmux, parce que screen tue des chatons lorsqu'on l'utilise.</troll></p>
<p>Sinon, c'est effectivement une autre solution, mais elle présente l'inconvénient qu'il n'y aura pas d'alerte en cas de problème, soit au niveau de screen, soit au niveau de ton script.</p>
<p>De plus, ça reste plus complexe à mettre en œuvre que <code>cron</code>, même si ce n'est pas la mère à boire.</p>
<p>Et non, tu n'es pas le seul à faire cela.</p>
<p>J'utilise le combo <s>screen</s> tmux + PHP pour des scripts <q>one shot</q> et pour des tâches non critiques et potentiellement assez longue, comme le nettoyage ou de l'analyse de code, de la génération de documentation, le remplissage de base de données lors de la mise en route d'un projet, etc.</p>
<p>Cependant, ce n'est pas de mon point de vue une solution viable en environnement de production.</p>