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.
[^] # Re: Mon avis sur la question.
Posté par romain . En réponse au message Cron Apache, gros traitements Php et stabilité. Évalué à 3.
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.