Forum Linux.général Cron Apache, gros traitements Php et stabilité

Posté par  .
Étiquettes : aucune
0
8
nov.
2005
Bonjour,

Je connais pas mal Php, je maîtrise les fonctions de base d'Apache, mais je débute complètement avec Linux.

Sur une architecture LAMP, je vais avoir besoin d'effectuer chaque nuit de gros traitements de maintenance sur mon serveur web.
De gros traitements, c'est : importer de gros fichiers textes de plusieurs dizaines de milliers d'enregistrements, les scanner, en contrôler les données, récupérer des fichiers images vers lesquels il pointent (plusieurs centaines à plusieurs milliers), recadrer ces images à différents formats puis les recopier ; pour enfin insérer tout ça proprement dans une base de données.

Tout ça, j'ai l'habitude de le faire en PHP (travail sur fichiers textes, librairie GD ou autre) et de programmer des crons qui me lancent tout ça au milieu de la nuit.
Mais que je commence à me poser des questions sur la viabilité et la fiabilité de ce système sur des traitements aussi lourds.


  • Je sais bien que l'on peux augmenter le timeout de scripts Php pour empêcher qu'ils tombent en rade. Mais malgré la stabilité de Php5 est-ce que c'est le bien langage le plus adapté pour ce genre de tâche ?

  • Dans quelle mesure les procédures stockées de Mysql5 apportent-elles un bénéfice de performance, pour ces gros traitement SQL ?

  • Les crons, on peut les lancer à des heures précises. Mais est-ce qu'on pourrait pas mieux organiser une liste séquentielle de tâches à effectuer ? Ce serait plus rassurant que de fixer arbitrairement des heures éloignées en priant pour que deux scripts ne fiissent pas par se marcher sur les pieds.





En dehors de Php + cron, sous une architecture LAMP, comment faire tout ça ?

J'ai commencé à me renseigner sur le shell en Linux, mais pour qui vient du Php, c'est effrayant. J'ai même du mal à identifier si ça peut être une solution pour moi.
N'hésitez à m'expliquer ça comme à un gamin de six ans, avec une histoire de grenouilles et faisant des grosses voix d'animaux, c'est comme ça que je comprends le mieux.
  • # Mon avis sur la question.

    Posté par  . Évalué à 5.

    Donc, personnellement, je ne pense pas que utiliser php pour ces taches soit une bonne idée.

    Bien que le shell unix puisse sembler assez ... obscure, il est le plus adapté pour ce genre de tache, et je te rassure, tu peux certainement te passer d'utiliser le quart des syntaxes barbares que tu as pu croiser dans les différents tutoriels sur le net !

    En effet, tu disposes d'outils puissants et rapides car écrit en C pour faire toutes ces taches.
    Par exemple:

    _ pour "parser" tes enregistrements depuis tes fichiers textes, tu as les outils awk, grep, sed, cut, tail, head qui sont voués à ces taches.

    _ pour retravailler tes images tu as convert issu de la suite ImageMagick qui excellera.

    _ mysql pour faire des requêtes mysql, l'exemple typique serait ici de "générer" un fichier contenant toutes tes requêtes puis de le faire executer par mysql à coup de mysql < le fichier.

    La souplesse de Linux n'exclut pas non plus une utilisation conjointe de php, le shell scripting, Perl/Python/...

    Maintenant, pour répondre concrétement à tes questions:


    # Je sais bien que l'on peux augmenter le timeout de scripts Php pour empêcher qu'ils tombent en rade. Mais malgré la stabilité de Php5 est-ce que c'est le bien langage le plus adapté pour ce genre de tâche ?


    Le timeout PHP n'a d'incidence que lorsque tu lances un script php via Apache il me semble. Or ce genre d'opération n'a pas à être lancé via apache, mais plutot par un appel php -f ton_script.php


    # Les crons, on peut les lancer à des heures précises. Mais est-ce qu'on pourrait pas mieux organiser une liste séquentielle de tâches à effectuer ? Ce serait plus rassurant que de fixer arbitrairement des heures éloignées en priant pour que deux scripts ne fiissent pas par se marcher sur les pieds.


    Sisi, c'est d'ailleurs la base du shell Unix !
    Soit trois script php : script1.php, script2.php et script3.php renvoyant 0 en cas de succés.
    Si tu ajoutes une crontab de cette forme:

    10 4 * * * php -f /chemin/script1.php && php -f /chemin/script2.php && php -f /chemin/script3.php

    Alors si script1.php échoue et renvoie une valeur différente de 0, le reste de la chaine ne sera pas executé.
    La syntaxe command1 && command2 équivaut à dire je lance command2 si et seulement si command1 s'est terminé avec succés.

    J'espère avoir éclairé un peu ta lanterne, si t'as d'autres questions ou besoin de précisions, hesite pas !
    • [^] # Re: Mon avis sur la question.

      Posté par  . Évalué à 1.

      T'inquiètes je n'hésiterai pas, surtout si on continue à me faire des vraies réponses comme ça.

      Merci pour ces quelque pistes, je vais creuser un peu tout ça , je sens que la cafetière va tourner jusque tard dans la nuit.

      Ah, déjà une question : à part les sites de référence de type Lea linux, t'aurais une ou deux adresses ou je pourrais trouver des infos pratiques ?

      Sinon je ferai chauffer google...
    • [^] # Re: Mon avis sur la question.

      Posté par  . Évalué à 3.

      Rien à rajouter, si ce n'est que PHP est stable et peut parfaitement assumer des traitements lourds, pourvu qu'on fasse gaffe à la consommation mémoire (j'ai une grosse base de prod de ~1 million de ligne/600Mo, des extractions/maj SQL assez lourdes régulières ; tout tourne en PHP, et je n'ai aucun incident applicatif à déplorer depuis pratiquement 1 an).

      En outre, pour la petite histoire, la base provient d'une fusion de 6 bases distinctes (2 millions de lignes, 1 Go de données), fusion assurée en PHP dans un script qui a tourné pendant ~4 heures sur une bonne machine. C'était un traitement moyennement lourd (rien à voir avec ce qui se fait en banque), mais qui m'a assuré de la bonne stabilité de PHP.

      Il est bon d'utiliser l'outil le plus adapté pour chaque tâche, mais il est aussi bon de ne pas se disséminer dans plusieurs langages différents, sous peine de rendre l'ensemble moins facile à appréhender.

      Cela dépend grandement de ce que tu fais, mais si ton code peut facilement s'articuler autour d'un truc objet, PHP et Perl sont parfaitement adéquats, et je dirais même préférables dans la mesure où ils peuvent être plus lisibles et modulables que des scripts bash.

      L'idée de chaîner les traitements dans le cron est pas mal ; je ne connaissais pas. Spontanément, j'aurais implémenté un automate au dessus de mon process pour gérer la synchronisation de chaque traitement, et notamment les rapports d'erreurs éventuelles, mais c'est un peu le syndrôme Not Invented Here qui se manifeste.
  • # php

    Posté par  . Évalué à 2.

    Mais que je commence à me poser des questions sur la viabilité et la fiabilité de ce système sur des traitements aussi lourds.

    serieux, je en vois pas pourquoi.
    le temps necessaire (la lourdeur) ne pose pas de probleme a cron donc c'est comme si tu lancais ceci depuis la ligne de commande.

    pour en revenir au PHP, c'est tres efficace (en terme de dev surtotu si tu connais dejà le php) en C tu va en chier grave avec les API graphique (j'ai mois même crée un script en php pour découper une image en fonction de zones blanche.. enfin bref, j'ai pas passé 3 jour à essayé de faire marcher les API, c'etait du tout cuit, un vrai bonheur)
    on peu considerer le PHP comme etant un script bash avec plein d'API, c'est de l'interpreté (ya plein de script sous unix/linux qui sont des script on en est pas mort)... ensuite quel obligation de perf tu as puisque ca tourne la nuit? est-ce important si au lieu de mettre 3 heure ca n'en mets qu'une seul ???? (pourquoi perdre des jour de programmation pour ...?)

    Mais est-ce qu'on pourrait pas mieux organiser une liste séquentielle de tâches à effectuer ?

    un batch quoi ?
    ben je te propose un fichier batch depuis lequel tu lance tes appel php, pas de probleme.



    En dehors de Php + cron, sous une architecture LAMP, comment faire tout ça ?

    le plus serieusement (d'apres ce que tu dis et que tu laisse voir par rapport a tes competences) : le PHP c'est bien pour toi.
  • # Ok, merci à tous

    Posté par  . Évalué à 2.

    La base sur laquelle je travaille est en majeure partie reconstruite chaque nuit par des fichiers externes. C'est la somme de travail à effectuer sur chaque enregistrement qui me faisait un peu peur. Pour le moment, tout avait été fait par un prédesseur sous Sql Server (procédures stockées) qui gère ça bien, mais l'évolution de la plateforme qui nous pousse à se tyourner vers Php + Mysql.

    Pour chaque enregistrement de chaque fichier, il faut successivement :
    extraire, comparer et sauvegarder les modifications des données, dézipper un fichier lié, y récupérer 5 photos (parfois de plusieurs Mo chacune), en faire différentes mignatures, coller tout ça dans la base, et passer au suivant en repérant les doublons et les incohérences.

    Quand on sait que ces étapes vont à terme être répétées plusieurs dizaines de milliers de fois par nuit, il y a de quoi se mettre sérieusement à réfléchir avant de se lancer à corps perdu dans le code.


    Je crois que je vais continuer à faire les traitements en Php5 comme auparavant. Je vais juste m'essayer aux précédures stockées Mysql5 qui peuvent me faire gagner du temps sur les étapes de contrôle.

    Pour le reste, je vais commencer des tests de performance, et envisager l'achat de serveurs suplémentaires si nécessaire.
    Je pense juste utiliser l'idée de Cron de Gérald qui a l'air pratique, ou utiliser un batch si ça facilite la gestion des alertes en cas de problème.

    Merci pour vos réponses.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.