Question

Je souhaite créer un processus d'arrière-plan et on m'a dit que ceux-ci sont généralement écrits en C ou quelque chose du genre. J'ai récemment découvert que PHP pouvait être utilisé pour créer un démon et j'espérais obtenir quelques conseils si je devais utiliser PHP de cette manière.

Voici mes exigences pour un démon.

  • Vérifie en permanence si une ligne a été ajouté à la table de base de données MySQL
  • Exécuter des commandes FFmpeg sur ce qui était récupéré de la base de données
  • Insérer le résultat dans la table MySQL

Je ne sais pas quoi d'autre je peux offrir pour aider à prendre cette décision. Juste pour ajouter, je n’ai jamais fait C auparavant. Seuls les scripts Java et PHP et les scripts bash basiques.

Est-ce que cela fait même beaucoup de différence de performance?

S'il vous plaît permettre à mon ignorance, je suis en train d'apprendre! :)

Merci à tous

Était-ce utile?

La solution

Comme d'autres l'ont noté, diverses versions de PHP ont des problèmes avec leurs éboueurs. Bien entendu, si vous savez que votre version ne présente pas de tels problèmes, vous l’éliminerez. Le fait est que vous ne savez pas (à coup sûr) tant que vous n'avez pas écrit le démon et que vous ne l'exécutez pas via valgrind pour voir si PHP installé fuit ou non sur une machine donnée. Donc, sur cette main, vous pouvez l'écrire juste pour découvrir que ce que Zend pense être corrigé peut encore être bogué, ou que vous avez affaire à une version légèrement plus ancienne de PHP ou à une extension. Icky.

L’autre problème concerne les signaux quelque peu bogués. D'après mon expérience, les gestionnaires de signaux ne sont pas toujours correctement saisis avec PHP, en particulier lorsque le signal est mis en file d'attente au lieu d'être fusionné. Ce n’est peut-être pas un problème pour vous, c’est-à-dire si vous devez juste gérer SIGINT / SIGUSR1 / SIGUSR2 / SIGHUP.

Donc, je suggère:

Si le démon est simple, continuez et utilisez PHP. Si cela vous semble trop compliqué ou si vous allouez beaucoup de mémoire, vous pouvez envisager de l'écrire en C après l'avoir prototypé en PHP.

Je suis une jolie personne qui dort fort. Cependant, je ne vois rien de mal à trouver quelque chose de rapide avec PHP (au-delà des cas que j’ai expliqués). Je ne vois également aucun inconvénient à utiliser PHP pour créer un prototype de quelque chose qui pourrait ou non être réécrit plus tard en C. Par exemple, la gestion des bases de données va être beaucoup plus simple si vous utilisez PHP, par opposition à la gestion des callbacks en utilisant d'autres interfaces en C. cette instance, pour un «one off», vous allez sûrement le faire beaucoup plus rapidement.

Autres conseils

Je serais enclin à effectuer cette tâche avec un travail cron, plutôt que d'interroger la base de données dans un démon.

Il est probable que votre commande FFmpeg mettra un certain temps à faire son travail, non? Dans ce cas, faut-il vraiment interroger constamment la base de données? Exécuter une tâche régulière à la minute (ou toutes les cinq, dix ou vingt minutes) ne serait-il pas un moyen plus simple d’atteindre le même résultat?

Php n'est ni meilleur ni pire pour ce genre de chose que tous les autres langages de script courants. Il a un accès assez complet à tous les appels système et aux utilitaires de bibliothèque dont vous auriez besoin pour effectuer ce type de travail. Si vous êtes plus à l'aise avec PHP pour les scripts, php fera le travail à votre place.

Le seul inconvénient, c’est que php n’est pas aussi omniprésent que, par exemple, perl ou python, qui est installé sur presque toutes les saveurs d’unix. Php ne se trouve que sur les systèmes qui vont servir du contenu Web dynamique. Ce n’est pas qu’un interpréteur Php soit trop gros ou trop coûteux à installer, mais si votre plus grande préoccupation est d’installer votre programme sur de nombreux systèmes, cela peut être un léger obstacle.

Je serai contraire et je vous recommande d'essayer le démon php. C'est apparemment la langue que vous connaissez le mieux. Vous allez probablement incorporer une minuterie dans tous les cas, afin de pouvoir dupliquer la fréquence d'interrogation dans la base de données. Il n'y a vraiment pas de pénalité tant que vous n'êtes pas en train de boucler naïvement une requête.

Si c'est quelque chose qui n'est pas exécuté fréquemment, vous pouvez également exécuter le php à partir de cron, en laissant votre code vider la file d'attente, puis mourir.

Mais n’ayez pas peur de vous en tenir à ce que vous savez le mieux, en première approximation.

Essayez de ne pas utiliser de déclencheurs. Ils imposeront un couplage inutile et ne sont pas amusants à tester et à déboguer.

Un problème avec la démonisation correcte d'un script PHP est que PHP n'a pas d'interface avec les appels système de dup () ou de dup2 (), nécessaires pour détacher les descripteurs de fichier.

Une tâche cron fonctionnerait probablement très bien si des actions quasi instantanées ne sont pas nécessaires.

Je suis sur le point de mettre en production un système que j'ai construit, basé sur le démon de mise en file d'attente 'beanstalkd'. J'envoie divers petits messages à partir d'appels de pages Web (dans ce cas, PHP) au démon, puis un script PHP les extrait de la file d'attente et effectue diverses tâches, telles que le redimensionnement des images ou la vérification des bases de données (en renvoyant souvent des informations via Memcache). à base de produits).

Pour éviter les longs processus, je l'ai encapsulé dans un script BASH qui, en fonction de la valeur renvoyée par le script ("exit (1);"), redémarrera le script pour chaque ) 50 tâches effectuées. S'il redémarre parce que je le planifie, il le fera instantanément. Toute autre valeur de sortie (la valeur par défaut est 0, donc je ne l'utilise pas) s'interromprait quelques secondes avant le redémarrage.

Exécuter comme un travail cron avec une périodicité bien déterminée, un script PHP peut faire le travail et la stabilité de la production est certainement réalisable. Vous souhaiterez peut-être limiter le nombre d'instances FFMpeg simultanées et vous assurer de disposer d'une journalisation complète des applications et de la gestion des exceptions. J'ai implémenté des processus de scrutation en continu en Java, ainsi que le script PHP croné toutes les dix minutes, et les deux font très bien l'affaire.

Vous pouvez envisager de créer un mysql déclencheur . qui exécute une commande système (par exemple, FFmpeg ) au lieu d'un démon. Si un certain retard ne pose pas de problème, vous pouvez également utiliser quelque chose dans cron qui s'exécute toutes les quelques minutes pour vérifier. Cron serait mon choix, si c'est une option.

Pour répondre à votre question, php convient parfaitement comme démon. Cela ne doit pas nécessairement être fait en C.

Si vous combinez les réponses de Kent Fredric, tokenmacguy et Domster, vous obtenez quelque chose d'utile.

php n'est probablement pas bon pour les longs temps d'exécution, gardons donc chaque cycle d'exécution court et assurons-nous que le système d'exploitation prend en charge le nettoyage de tous les problèmes de mémoire. En tant qu'outil pour démarrer votre script php, cron peut être un bon outil. Et si vous le faites comme ça, il n'y a pas beaucoup de différence entre les langues.

Cependant, la question est toujours d'actualité. Php est-il même capable de fonctionner comme un démon normal pendant de longues périodes (quelques années)? Ou alors, des fuites de mémoire diverses vont-elles dévorer tout votre bélier et tuer le système?

/ Johan

Si vous le faites, faites attention aux fuites de mémoire. PHP 5.2 a quelques problèmes avec son ramasse-miettes, selon this (corrigé dans 5.3). Peut-être vaut-il mieux utiliser cron, le script commence donc à nettoyer chaque exécution.

Pour ce que vous avez décrit, je choisirais un démon. Veillez à rester en veille dans la boucle du sondage afin de ne pas bombarder la base de données en l'absence de nouvelles tâches. Un travail cron fonctionne mieux pour les travaux de type workflow / report où aucun événement particulier ne déclenche la prochaine exécution.

Comme mentionné, PHP rencontre des problèmes de gestion de la mémoire. Vous devez vous assurer de tester votre code pour détecter les fuites de mémoire, car celles-ci s'accumuleraient avec le temps, dans un script long. PHP n'a pas de véritable corbeille. Il repose sur le comptage de références, ce qui signifie que les références cycliques vont provoquer des fuites. Si vous en êtes conscient, vous pouvez coder.

Si vous avez décidé de suivre la voie du démon, il existe un excellent module PEAR appelé System_Daemon que j'ai récemment utilisé avec succès sur une installation PHP 5.3.0. . Il est documenté sur le blog des auteurs: http://kevin.vanzonneveld.net/techblog/article / create_daemons_in_php

Si vous avez installé PEAR, vous pouvez installer ce module en utilisant:

pear install -f System_Daemon

Vous devrez également créer un script d'initialisation: /etc/init.d/<votre_nom_démone>

Ensuite, vous pouvez:

  • Démon de démarrage: /etc/init.d/projNotifMailDaemon start
  • Stop Daemon: /etc/init.d/projNotifMailDaemon stop

Les journaux sont conservés dans: /var/log/<votre_nom_démone>.log

Je ne le recommanderais pas. PHP n'est pas conçu pour une exécution à long terme. Son conçu principalement avec des pages de courte durée.

D'après mon expérience, PHP peut rencontrer des problèmes de fuite de mémoire pour certaines des tâches les plus importantes.

Un travail cron et un peu de script bash devraient contenir tout ce dont vous avez besoin. Vous pouvez faire des choses comme:

$file=`mysqlquery -h server < "select file from table;"`
ffmpeg $file -fps 50 output.a etc.

donc bash serait plus facile à écrire, à porter et à maintenir à mon humble avis que d’utiliser PHP.

Si vous savez ce que vous faites bien. Vous devez bien comprendre votre système d'exploitation. PHP ne convient généralement pas à la plupart des démons car il n’est pas threadé et n’a pas de système décent basé sur les événements pour toutes les tâches. Cependant, si cela répond à vos besoins, aucun problème. Le PHP moderne (5.3+) est vraiment stable et ne présente aucune fuite de mémoire. Tant que vous activez le CPG et que vous n'implémentez pas vos propres fuites de mémoire, tout ira bien.

Voici les statistiques d'un démon que je lance: disponibilité 17 jours (dernier redémarrage en raison de la mise à niveau de PHP). octets écrits: 200 Go connexions: des centaines connexions gérées, des centaines de milliers éléments / demandes traitées: millions

node.js est généralement mieux adapté bien que présente quelques inconvénients mineurs. Quelques tentatives d’amélioration de PHP dans les mêmes domaines ont été faites, mais elles ne sont pas vraiment formidables.

Cron job? Oui.

Daemon qui tourne pour toujours? Non.

PHP ne dispose pas d'un ramasse-miettes (ou du moins, la dernière fois que j'ai vérifié, il n'en avait pas). Par conséquent, si vous créez une référence circulaire, elle ne sera JAMAIS nettoyée - du moins pas avant la fin de l'exécution du script principal. Dans un processus démon, cela n’est à peu près jamais.

S'ils ont ajouté un catalogue global dans de nouvelles versions, alors vous le pouvez.

Allez-y. Je devais le faire une fois aussi. Comme d'autres l'ont dit, ce n'est pas idéal, mais ça va être fini. En utilisant Windows, non? Bien.

Si vous n'en avez besoin que pour fonctionner occasionnellement (une fois par heure, etc.). Créez un nouveau raccourci vers votre firefox, placez-le dans un endroit approprié. Ouvrez les propriétés du raccourci, modifiez " Cible " à:

"C:\Program Files\Mozilla Firefox\firefox.exe" http://localhost/path/to/script.php

Allez au Panneau de configuration > Tâches planifiées Pointez votre nouvelle tâche planifiée sur le raccourci.

Si vous en avez besoin pour fonctionner en permanence ou en pseudo-constance, vous devez pimenter un peu le script.

Lancez votre script avec

set_time_limit(0);
ob_implicit_flush(true);

Si le script utilise une boucle (comme tant que ), vous devez vider le tampon:

$i=0;
while($i<sizeof($my_array)){
     //do stuff
     flush();           
     ob_clean();
     sleep(17);
     $i++;
}
Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top