Pensez-vous que le paramètre d'allocation mémoire par défaut ( 8Mo
par script ), suffira pour qu'il n'y ait pas d'erreur par manque de
mémoire allouée ?
Sinon, pensez-vous que ce script pourrait fonctionner avec soit 16Mo,
soit 32Mo configurés dans le fichiers /etc/php.ini de configuration de PHP ?
Le serveur est un serveur dédié, pas de problème pour changer la
configuration.
Le script est relativement peu gourmand en ressources MySQL: Une
grande boucle de lecture, plus un chouïa de lecture par ci par là durant
l'exécution, plus des insert ponctuels non groupés. La boucle principale
de lecture, est la seule dont la mémoire n'est libérée, qu'à la fin de
l'exécution du script, la lecture SQL comme vous le savez, est
bufferisée, et les données lues transitent entre la table SQL lue et la
mémoire, de manière cool en terme d'occupation mémoire.
Ce script n'est pas destiné à un usage intensif, il sert uniquement à
la mise à jour des statistiques sur les pronostics de mon site
partenaire, ces mises à jour auront lieu une fois par jour, et à priori,
ne concerneront que les pronostics de la veille.
Merci beaucoup de vos réponses.
Jean-Francois Ortolo
--
Visitez mon site gratuit donnant des Statistiques
et des Historiques Graphiques sur les Courses de Chevaux
http://www.ortolojf-courses.com
Pensez-vous que le paramètre d'allocation mémoire par défaut ( 8Mo par script ), suffira pour qu'il n'y ait pas d'erreur par manque de mémoire allouée ?
Je ne pense pas que la taille (en LOC) du script ait une influence majeure sur la conso mémoire !-) Si tu veux, je peux te bouffer toute la mémoire avec un script de trois/quatres lignes.
Bonjour
Je suis en train de terminer un script PHP, assez gros.
Pensez-vous que le paramètre d'allocation mémoire par défaut ( 8Mo par
script ), suffira pour qu'il n'y ait pas d'erreur par manque de mémoire
allouée ?
Je ne pense pas que la taille (en LOC) du script ait une influence
majeure sur la conso mémoire !-) Si tu veux, je peux te bouffer toute la
mémoire avec un script de trois/quatres lignes.
Pensez-vous que le paramètre d'allocation mémoire par défaut ( 8Mo par script ), suffira pour qu'il n'y ait pas d'erreur par manque de mémoire allouée ?
Je ne pense pas que la taille (en LOC) du script ait une influence majeure sur la conso mémoire !-) Si tu veux, je peux te bouffer toute la mémoire avec un script de trois/quatres lignes.
Thierry B.
--{ Jean-Francois Ortolo a plopé ceci: }--
Je suis en train de terminer un script PHP, assez gros. longueur : 562500 caractères ascii nbre de lignes : 21800 lignes
J'y crois pas, c'est impossible. C'est un troll patatoïde.
-- Divorce d'état: revenus doublés. C'est la France qui avance.
--{ Jean-Francois Ortolo a plopé ceci: }--
Je suis en train de terminer un script PHP, assez gros.
longueur : 562500 caractères ascii
nbre de lignes : 21800 lignes
J'y crois pas, c'est impossible. C'est un troll patatoïde.
--
Divorce d'état: revenus doublés. C'est la France qui avance.
Pensez-vous que le paramètre d'allocation mémoire par défaut ( 8Mo par script ), suffira pour qu'il n'y ait pas d'erreur par manque de mémoire allouée ?
Je ne pense pas que la taille (en LOC) du script ait une influence majeure sur la conso mémoire !-) Si tu veux, je peux te bouffer toute la mémoire avec un script de trois/quatres lignes.
aoué ? fait péter les 4 lignes s'il te plait.
merci d'avance
Bruno Desthuilliers a exposé le 01/02/2008 :
Bonjour
Je suis en train de terminer un script PHP, assez gros.
Pensez-vous que le paramètre d'allocation mémoire par défaut ( 8Mo par
script ), suffira pour qu'il n'y ait pas d'erreur par manque de mémoire
allouée ?
Je ne pense pas que la taille (en LOC) du script ait une influence majeure
sur la conso mémoire !-) Si tu veux, je peux te bouffer toute la mémoire avec
un script de trois/quatres lignes.
Pensez-vous que le paramètre d'allocation mémoire par défaut ( 8Mo par script ), suffira pour qu'il n'y ait pas d'erreur par manque de mémoire allouée ?
Je ne pense pas que la taille (en LOC) du script ait une influence majeure sur la conso mémoire !-) Si tu veux, je peux te bouffer toute la mémoire avec un script de trois/quatres lignes.
aoué ? fait péter les 4 lignes s'il te plait.
merci d'avance
Jean-Francois Ortolo
Bonjour
Je suis en train de terminer un script PHP, assez gros.
Pensez-vous que le paramètre d'allocation mémoire par défaut ( 8Mo par script ), suffira pour qu'il n'y ait pas d'erreur par manque de mémoire allouée ?
Je ne pense pas que la taille (en LOC) du script ait une influence majeure sur la conso mémoire !-) Si tu veux, je peux te bouffer toute la mémoire avec un script de trois/quatres lignes.
Bonjour Monsieur
Il est vrai que mon script a un certain nombre de variables indicées, mais il me semble qu'au total, l'occupation mémoire spécifique de ces variables, devrait au total, rester largement en dessous de 1 Mo.
Le volume occupé par toutes les variables, est relativement constant au fur et à mesure de l'exécution du script, mais il y a bien libération de la mémoire avec des unset, au fur et à mesure, ce qui éventuellement peut poser des problèmes d'allocation mémoire.
Je m'inquitéais surtout à cause de la taille en octets de mon script, qui fera environ 562500 octets de long. ( un peu plus d'un demi-méga-octets quand même ).
Je suppose que dans un environnement serveur Linux ( actuellement RedHat 7.2, bientôt Linux Fedora Core 4 ), la mémoire RAM n'est pas segmentée, c'est la moindre des choses...
Merci beaucoup de votre réponse.
Bien à vous.
Amicalement.
Jean-Francois Ortolo
-- Visitez mon site gratuit donnant des Statistiques et des Historiques Graphiques sur les Courses de Chevaux http://www.ortolojf-courses.com
Bonjour
Je suis en train de terminer un script PHP, assez gros.
Pensez-vous que le paramètre d'allocation mémoire par défaut ( 8Mo
par script ), suffira pour qu'il n'y ait pas d'erreur par manque de
mémoire allouée ?
Je ne pense pas que la taille (en LOC) du script ait une influence
majeure sur la conso mémoire !-) Si tu veux, je peux te bouffer toute la
mémoire avec un script de trois/quatres lignes.
Bonjour Monsieur
Il est vrai que mon script a un certain nombre de variables indicées,
mais il me semble qu'au total, l'occupation mémoire spécifique de ces
variables, devrait au total, rester largement en dessous de 1 Mo.
Le volume occupé par toutes les variables, est relativement constant
au fur et à mesure de l'exécution du script, mais il y a bien libération
de la mémoire avec des unset, au fur et à mesure, ce qui éventuellement
peut poser des problèmes d'allocation mémoire.
Je m'inquitéais surtout à cause de la taille en octets de mon script,
qui fera environ 562500 octets de long. ( un peu plus d'un
demi-méga-octets quand même ).
Je suppose que dans un environnement serveur Linux ( actuellement
RedHat 7.2, bientôt Linux Fedora Core 4 ), la mémoire RAM n'est pas
segmentée, c'est la moindre des choses...
Merci beaucoup de votre réponse.
Bien à vous.
Amicalement.
Jean-Francois Ortolo
--
Visitez mon site gratuit donnant des Statistiques
et des Historiques Graphiques sur les Courses de Chevaux
http://www.ortolojf-courses.com
Pensez-vous que le paramètre d'allocation mémoire par défaut ( 8Mo par script ), suffira pour qu'il n'y ait pas d'erreur par manque de mémoire allouée ?
Je ne pense pas que la taille (en LOC) du script ait une influence majeure sur la conso mémoire !-) Si tu veux, je peux te bouffer toute la mémoire avec un script de trois/quatres lignes.
Bonjour Monsieur
Il est vrai que mon script a un certain nombre de variables indicées, mais il me semble qu'au total, l'occupation mémoire spécifique de ces variables, devrait au total, rester largement en dessous de 1 Mo.
Le volume occupé par toutes les variables, est relativement constant au fur et à mesure de l'exécution du script, mais il y a bien libération de la mémoire avec des unset, au fur et à mesure, ce qui éventuellement peut poser des problèmes d'allocation mémoire.
Je m'inquitéais surtout à cause de la taille en octets de mon script, qui fera environ 562500 octets de long. ( un peu plus d'un demi-méga-octets quand même ).
Je suppose que dans un environnement serveur Linux ( actuellement RedHat 7.2, bientôt Linux Fedora Core 4 ), la mémoire RAM n'est pas segmentée, c'est la moindre des choses...
Merci beaucoup de votre réponse.
Bien à vous.
Amicalement.
Jean-Francois Ortolo
-- Visitez mon site gratuit donnant des Statistiques et des Historiques Graphiques sur les Courses de Chevaux http://www.ortolojf-courses.com
Olivier Miakinen
Je ne pense pas que la taille (en LOC) du script ait une influence majeure sur la conso mémoire !-) Si tu veux, je peux te bouffer toute la mémoire avec un script de trois/quatres lignes.
aoué ? fait péter les 4 lignes s'il te plait.
Je peux jouer ? J'essaierais bien un truc comme ça :
Je ne pense pas que la taille (en LOC) du script ait une influence majeure
sur la conso mémoire !-) Si tu veux, je peux te bouffer toute la mémoire avec
un script de trois/quatres lignes.
aoué ? fait péter les 4 lignes s'il te plait.
Je peux jouer ? J'essaierais bien un truc comme ça :
Je ne pense pas que la taille (en LOC) du script ait une influence majeure sur la conso mémoire !-) Si tu veux, je peux te bouffer toute la mémoire avec un script de trois/quatres lignes.
aoué ? fait péter les 4 lignes s'il te plait.
Je peux jouer ? J'essaierais bien un truc comme ça :
Je suis en train de terminer un script PHP, assez gros. longueur : 562500 caractères ascii nbre de lignes : 21800 lignes
J'y crois pas, c'est impossible. C'est un troll patatoïde.
Bonjour Monsieur
Je vous garantis, que je suis bien en train de mettre au point ( terminer de programmer ) ce script, qui a actuellement, pour être précis, les dimensions suivantes:
longueur : 562423 caractères ascii ( ou octets si vous préférez ), nbre lignes : 21781 lignes
Je n'ai pas encore testé ce script, pour la simple raison qu'il n'est pas entièrement terminé. Cependant, j'ai testé et mis au point ce script à un moment où il était réduit à une fraction de ses fonctionnalités, à savoir le nettoyage en amont des données qu'il traite. Il a ensuite été complété par le calcul des variables statistiques. Je maîtrise bien la structure du script, et il compile par faitement bien, ce qui je le reconnais, ne veut pas dire qu'il n'y a pas quelques erreurs d'orthographe de variables...
Ces données traitées, sont lues dans une table SQL dans la boucle la plus externe, c'est le traitement SQL qui nécessite le plus de mémoire, puisque le buffer n'est libéré qu'à la fin de l'exécution du script.
Les dimensions actuelles du script, sont motivées par le fait que ces données font l'objet d'un traitement sophistiqué de calcul, pour calculer les données statistiques temporaires, puis finales.
Ces données statistiques temporaires puis finales, sont contenues dans des variables indicées à deux et à trois indices, dont j'ai déjà dit, que leur volume global est certainement inférieur à 1Mo.
Cependant, le fait que certaines variables temporaires voient leur mémoire libérée en cours de route ( par des unset ), fait que la mémoire effectivement allouée, peut être supérieure à l'addition des mémoires de toutes les variables.
Je reconnais qu'un script aussi important est peu courant en PHP, mais il n'y a pas d'autre solution pour calculer des statistiques qui doivent pouvoir être mises à jour quotidiennement, sans que celà n'ait d'impact négatif sur la justesse des statistiques.
D'autre part, il sera possible, avec cette approche, d'afficher des stats en choisissant soit des catégories de stats ( nom du pronostiqueur par exemple puisque ce sont des stats de pronostics de courses de chevaux ), soit des périodes prise en compte des stats ( exemple les 6 premier mois de 2006, ou toute l'année 2007, etc... ).
Celà dit, si une telle dimension de script est si inhabituelle, est-il possible à priori, de répondre à la question que je me pose, qui conditionne la faisabilité de ce projet ?
Merci beaucoup de votre réponse.
Jean-Francois Ortolo
-- Visitez mon site gratuit donnant des Statistiques et des Historiques Graphiques sur les Courses de Chevaux http://www.ortolojf-courses.com
--{ Jean-Francois Ortolo a plopé ceci: }--
Je suis en train de terminer un script PHP, assez gros.
longueur : 562500 caractères ascii
nbre de lignes : 21800 lignes
J'y crois pas, c'est impossible. C'est un troll patatoïde.
Bonjour Monsieur
Je vous garantis, que je suis bien en train de mettre au point (
terminer de programmer ) ce script, qui a actuellement, pour être
précis, les dimensions suivantes:
longueur : 562423 caractères ascii ( ou octets si vous préférez ),
nbre lignes : 21781 lignes
Je n'ai pas encore testé ce script, pour la simple raison qu'il n'est
pas entièrement terminé. Cependant, j'ai testé et mis au point ce script
à un moment où il était réduit à une fraction de ses fonctionnalités, à
savoir le nettoyage en amont des données qu'il traite. Il a ensuite été
complété par le calcul des variables statistiques. Je maîtrise bien la
structure du script, et il compile par faitement bien, ce qui je le
reconnais, ne veut pas dire qu'il n'y a pas quelques erreurs
d'orthographe de variables...
Ces données traitées, sont lues dans une table SQL dans la boucle la
plus externe, c'est le traitement SQL qui nécessite le plus de mémoire,
puisque le buffer n'est libéré qu'à la fin de l'exécution du script.
Les dimensions actuelles du script, sont motivées par le fait que ces
données font l'objet d'un traitement sophistiqué de calcul, pour
calculer les données statistiques temporaires, puis finales.
Ces données statistiques temporaires puis finales, sont contenues
dans des variables indicées à deux et à trois indices, dont j'ai déjà
dit, que leur volume global est certainement inférieur à 1Mo.
Cependant, le fait que certaines variables temporaires voient leur
mémoire libérée en cours de route ( par des unset ), fait que la mémoire
effectivement allouée, peut être supérieure à l'addition des mémoires de
toutes les variables.
Je reconnais qu'un script aussi important est peu courant en PHP, mais
il n'y a pas d'autre solution pour calculer des statistiques qui
doivent pouvoir être mises à jour quotidiennement, sans que celà n'ait
d'impact négatif sur la justesse des statistiques.
D'autre part, il sera possible, avec cette approche, d'afficher des
stats en choisissant soit des catégories de stats ( nom du pronostiqueur
par exemple puisque ce sont des stats de pronostics de courses de
chevaux ), soit des périodes prise en compte des stats ( exemple les 6
premier mois de 2006, ou toute l'année 2007, etc... ).
Celà dit, si une telle dimension de script est si inhabituelle,
est-il possible à priori, de répondre à la question que je me pose, qui
conditionne la faisabilité de ce projet ?
Merci beaucoup de votre réponse.
Jean-Francois Ortolo
--
Visitez mon site gratuit donnant des Statistiques
et des Historiques Graphiques sur les Courses de Chevaux
http://www.ortolojf-courses.com
Je suis en train de terminer un script PHP, assez gros. longueur : 562500 caractères ascii nbre de lignes : 21800 lignes
J'y crois pas, c'est impossible. C'est un troll patatoïde.
Bonjour Monsieur
Je vous garantis, que je suis bien en train de mettre au point ( terminer de programmer ) ce script, qui a actuellement, pour être précis, les dimensions suivantes:
longueur : 562423 caractères ascii ( ou octets si vous préférez ), nbre lignes : 21781 lignes
Je n'ai pas encore testé ce script, pour la simple raison qu'il n'est pas entièrement terminé. Cependant, j'ai testé et mis au point ce script à un moment où il était réduit à une fraction de ses fonctionnalités, à savoir le nettoyage en amont des données qu'il traite. Il a ensuite été complété par le calcul des variables statistiques. Je maîtrise bien la structure du script, et il compile par faitement bien, ce qui je le reconnais, ne veut pas dire qu'il n'y a pas quelques erreurs d'orthographe de variables...
Ces données traitées, sont lues dans une table SQL dans la boucle la plus externe, c'est le traitement SQL qui nécessite le plus de mémoire, puisque le buffer n'est libéré qu'à la fin de l'exécution du script.
Les dimensions actuelles du script, sont motivées par le fait que ces données font l'objet d'un traitement sophistiqué de calcul, pour calculer les données statistiques temporaires, puis finales.
Ces données statistiques temporaires puis finales, sont contenues dans des variables indicées à deux et à trois indices, dont j'ai déjà dit, que leur volume global est certainement inférieur à 1Mo.
Cependant, le fait que certaines variables temporaires voient leur mémoire libérée en cours de route ( par des unset ), fait que la mémoire effectivement allouée, peut être supérieure à l'addition des mémoires de toutes les variables.
Je reconnais qu'un script aussi important est peu courant en PHP, mais il n'y a pas d'autre solution pour calculer des statistiques qui doivent pouvoir être mises à jour quotidiennement, sans que celà n'ait d'impact négatif sur la justesse des statistiques.
D'autre part, il sera possible, avec cette approche, d'afficher des stats en choisissant soit des catégories de stats ( nom du pronostiqueur par exemple puisque ce sont des stats de pronostics de courses de chevaux ), soit des périodes prise en compte des stats ( exemple les 6 premier mois de 2006, ou toute l'année 2007, etc... ).
Celà dit, si une telle dimension de script est si inhabituelle, est-il possible à priori, de répondre à la question que je me pose, qui conditionne la faisabilité de ce projet ?
Merci beaucoup de votre réponse.
Jean-Francois Ortolo
-- Visitez mon site gratuit donnant des Statistiques et des Historiques Graphiques sur les Courses de Chevaux http://www.ortolojf-courses.com
doug713705
Le vendredi 1 février 2008 19:15, Jean-Francois Ortolo s'est exprimé de la sorte sur fr.comp.lang.php :
Je m'inquitéais surtout à cause de la taille en octets de mon script, qui fera environ 562500 octets de long. ( un peu plus d'un demi-méga-octets quand même ).
C'est plutôt du coté du temps d'exécution du script que ça risque de ne pas passer.
Pour cela, ajuster la variable "max_execution_time" devrait sauver l'affaire.
-- @+ Doug - Linux user #307925 - Gentoo rocks ;-) [ Plus ou moins avec une chance de peut-être ] - Pour me contacter, enlever nospam (2X) -
Le vendredi 1 février 2008 19:15, Jean-Francois Ortolo s'est exprimé de la
sorte sur fr.comp.lang.php :
Je m'inquitéais surtout à cause de la taille en octets de mon script,
qui fera environ 562500 octets de long. ( un peu plus d'un
demi-méga-octets quand même ).
C'est plutôt du coté du temps d'exécution du script que ça risque de ne pas
passer.
Pour cela, ajuster la variable "max_execution_time" devrait sauver
l'affaire.
--
@+
Doug - Linux user #307925 - Gentoo rocks ;-)
[ Plus ou moins avec une chance de peut-être ]
- Pour me contacter, enlever nospam (2X) -
Le vendredi 1 février 2008 19:15, Jean-Francois Ortolo s'est exprimé de la sorte sur fr.comp.lang.php :
Je m'inquitéais surtout à cause de la taille en octets de mon script, qui fera environ 562500 octets de long. ( un peu plus d'un demi-méga-octets quand même ).
C'est plutôt du coté du temps d'exécution du script que ça risque de ne pas passer.
Pour cela, ajuster la variable "max_execution_time" devrait sauver l'affaire.
-- @+ Doug - Linux user #307925 - Gentoo rocks ;-) [ Plus ou moins avec une chance de peut-être ] - Pour me contacter, enlever nospam (2X) -
Jean-Francois Ortolo
C'est plutôt du coté du temps d'exécution du script que ça risque de ne pas passer.
Pour cela, ajuster la variable "max_execution_time" devrait sauver l'affaire.
Bonjour Monsieur
Je pense qu'il n'y aura pas de problèmes de ce côté-là, parce que je peux, pour traiter plus d'une journée de courses, spécifier une date début et une date fin, donc réduire le traitement de chaque appel au script, à une seule journée de courses.
Actuellement, le temps limite d'exécution est de 30 secondes.
Il y a un nombre limité de pronostiqueurs ( moins de 10 ), évidemment un nombre limité de courses et de résultats par jour, et ce qui prendra du temps à l'exécution, sera au pif, 1/3 ou 1/4 pour le nettoyage des données en amont ( qui sont effectivement un peu parasitées ), et 2/3 ou 3/4 pour la mise à jour des statistiques, et leur intégration à la base de données.
A un moment où il n'y avait comme fonctionnalité, que le nettoyage des données, j'avais un temps d'exécution limite correspondant à un peu plus d'un mois de courses ( donc 30 jours ). Je pense donc que proportionnellement parlant, il ne devrait pas y avoir de difficultés pour, au pire, mettre à jour les stats une journée à la fois.
L'appel à ce script PHP se fera à partir d'un script Shell qui lancera répétitivement le programme curl avec les paramètres qui vont bien, les dates début et fin seront calculées dans le script Shell de manière adéquate, et il y aura même une procédure automatique de reprise sur incident, au cas où le script n'arrive pas jusqu'au bout de son exécution ( annulation et retour à l'état antérieur des données en base de données. )
Merci beaucoup de votre réponse, qui m'apporte effectivement également la réponse au problème du temps limite d'exécution.
Bien à vous.
Amicalement.
Jean-Francois Ortolo
-- Visitez mon site gratuit donnant des Statistiques et des Historiques Graphiques sur les Courses de Chevaux http://www.ortolojf-courses.com
C'est plutôt du coté du temps d'exécution du script que ça risque de ne pas
passer.
Pour cela, ajuster la variable "max_execution_time" devrait sauver
l'affaire.
Bonjour Monsieur
Je pense qu'il n'y aura pas de problèmes de ce côté-là, parce que je
peux, pour traiter plus d'une journée de courses, spécifier une date
début et une date fin, donc réduire le traitement de chaque appel au
script, à une seule journée de courses.
Actuellement, le temps limite d'exécution est de 30 secondes.
Il y a un nombre limité de pronostiqueurs ( moins de 10 ), évidemment
un nombre limité de courses et de résultats par jour, et ce qui prendra
du temps à l'exécution, sera au pif, 1/3 ou 1/4 pour le nettoyage des
données en amont ( qui sont effectivement un peu parasitées ), et 2/3 ou
3/4 pour la mise à jour des statistiques, et leur intégration à la base
de données.
A un moment où il n'y avait comme fonctionnalité, que le nettoyage
des données, j'avais un temps d'exécution limite correspondant à un peu
plus d'un mois de courses ( donc 30 jours ). Je pense donc que
proportionnellement parlant, il ne devrait pas y avoir de difficultés
pour, au pire, mettre à jour les stats une journée à la fois.
L'appel à ce script PHP se fera à partir d'un script Shell qui
lancera répétitivement le programme curl avec les paramètres qui vont
bien, les dates début et fin seront calculées dans le script Shell de
manière adéquate, et il y aura même une procédure automatique de reprise
sur incident, au cas où le script n'arrive pas jusqu'au bout de son
exécution ( annulation et retour à l'état antérieur des données en base
de données. )
Merci beaucoup de votre réponse, qui m'apporte effectivement
également la réponse au problème du temps limite d'exécution.
Bien à vous.
Amicalement.
Jean-Francois Ortolo
--
Visitez mon site gratuit donnant des Statistiques
et des Historiques Graphiques sur les Courses de Chevaux
http://www.ortolojf-courses.com
C'est plutôt du coté du temps d'exécution du script que ça risque de ne pas passer.
Pour cela, ajuster la variable "max_execution_time" devrait sauver l'affaire.
Bonjour Monsieur
Je pense qu'il n'y aura pas de problèmes de ce côté-là, parce que je peux, pour traiter plus d'une journée de courses, spécifier une date début et une date fin, donc réduire le traitement de chaque appel au script, à une seule journée de courses.
Actuellement, le temps limite d'exécution est de 30 secondes.
Il y a un nombre limité de pronostiqueurs ( moins de 10 ), évidemment un nombre limité de courses et de résultats par jour, et ce qui prendra du temps à l'exécution, sera au pif, 1/3 ou 1/4 pour le nettoyage des données en amont ( qui sont effectivement un peu parasitées ), et 2/3 ou 3/4 pour la mise à jour des statistiques, et leur intégration à la base de données.
A un moment où il n'y avait comme fonctionnalité, que le nettoyage des données, j'avais un temps d'exécution limite correspondant à un peu plus d'un mois de courses ( donc 30 jours ). Je pense donc que proportionnellement parlant, il ne devrait pas y avoir de difficultés pour, au pire, mettre à jour les stats une journée à la fois.
L'appel à ce script PHP se fera à partir d'un script Shell qui lancera répétitivement le programme curl avec les paramètres qui vont bien, les dates début et fin seront calculées dans le script Shell de manière adéquate, et il y aura même une procédure automatique de reprise sur incident, au cas où le script n'arrive pas jusqu'au bout de son exécution ( annulation et retour à l'état antérieur des données en base de données. )
Merci beaucoup de votre réponse, qui m'apporte effectivement également la réponse au problème du temps limite d'exécution.
Bien à vous.
Amicalement.
Jean-Francois Ortolo
-- Visitez mon site gratuit donnant des Statistiques et des Historiques Graphiques sur les Courses de Chevaux http://www.ortolojf-courses.com
doug713705
Le samedi 2 février 2008 13:14, Jean-Francois Ortolo s'est exprimé de la sorte sur fr.comp.lang.php :
L'appel à ce script PHP se fera à partir d'un script Shell qui lancera répétitivement le programme curl avec les paramètres qui vont bien
Pourquoi utiliser curl alors qu'un script php peut s'exécuter directement ? Si le script ne fait que des insertions/mises à jour/suppressions de données et aucun d'affichage, une tâche cron et hop ca roulaize, non ?
-- @+ Doug - Linux user #307925 - Gentoo rocks ;-) [ Plus ou moins avec une chance de peut-être ] - Pour me contacter, enlever nospam (2X) -
Le samedi 2 février 2008 13:14, Jean-Francois Ortolo s'est exprimé de la
sorte sur fr.comp.lang.php :
L'appel à ce script PHP se fera à partir d'un script Shell qui
lancera répétitivement le programme curl avec les paramètres qui vont
bien
Pourquoi utiliser curl alors qu'un script php peut s'exécuter directement ?
Si le script ne fait que des insertions/mises à jour/suppressions de données
et aucun d'affichage, une tâche cron et hop ca roulaize, non ?
--
@+
Doug - Linux user #307925 - Gentoo rocks ;-)
[ Plus ou moins avec une chance de peut-être ]
- Pour me contacter, enlever nospam (2X) -
Le samedi 2 février 2008 13:14, Jean-Francois Ortolo s'est exprimé de la sorte sur fr.comp.lang.php :
L'appel à ce script PHP se fera à partir d'un script Shell qui lancera répétitivement le programme curl avec les paramètres qui vont bien
Pourquoi utiliser curl alors qu'un script php peut s'exécuter directement ? Si le script ne fait que des insertions/mises à jour/suppressions de données et aucun d'affichage, une tâche cron et hop ca roulaize, non ?
-- @+ Doug - Linux user #307925 - Gentoo rocks ;-) [ Plus ou moins avec une chance de peut-être ] - Pour me contacter, enlever nospam (2X) -
Jean-Francois Ortolo
Pourquoi utiliser curl alors qu'un script php peut s'exécuter directement ? Si le script ne fait que des insertions/mises à jour/suppressions de données et aucun d'affichage, une tâche cron et hop ca roulaize, non ?
A vrai dire...
J'ai besoin que le script me rende quelque chose disant qu'il est allé jusqu'au bout sans problème.
Je fais çà en lui faisant afficher la chaîne: "OK" en fin de script.
Je me suis arrangé pour que le script Shell prenne automatiquement en compte l'absence ou la présence de cette chaîne rendue par le script, pour faire un traitement de reprise sur incident ( annulation des opérations sur bdd ) si cette chaîne n'est pas envoyée par le script.
Sinon, je sais pas comment le processus Shell de l'interpréteur PHP en mode CLI, pourrait rendre un numéro interprétable par le script Shell, en sortie du script PHP.
Je sais que quand on lance une commande dans un script Shell, la variable $? rend le code de retour de la commande. Mais je ne sais pas comment agir sur le code de retour du script PHP, quand il est interprété ( ou compilé just in time ) par l'interpréteur PHP en mode CLI.
Merci beaucoup de ta réponse.
Amicalement.
Jean-Francois Ortolo
-- Visitez mon site gratuit donnant des Statistiques et des Historiques Graphiques sur les Courses de Chevaux http://www.ortolojf-courses.com
Pourquoi utiliser curl alors qu'un script php peut s'exécuter directement ?
Si le script ne fait que des insertions/mises à jour/suppressions de données
et aucun d'affichage, une tâche cron et hop ca roulaize, non ?
A vrai dire...
J'ai besoin que le script me rende quelque chose disant qu'il est
allé jusqu'au bout sans problème.
Je fais çà en lui faisant afficher la chaîne: "OK" en fin de script.
Je me suis arrangé pour que le script Shell prenne automatiquement en
compte l'absence ou la présence de cette chaîne rendue par le script,
pour faire un traitement de reprise sur incident ( annulation des
opérations sur bdd ) si cette chaîne n'est pas envoyée par le script.
Sinon, je sais pas comment le processus Shell de l'interpréteur PHP
en mode CLI, pourrait rendre un numéro interprétable par le script
Shell, en sortie du script PHP.
Je sais que quand on lance une commande dans un script Shell, la
variable $? rend le code de retour de la commande. Mais je ne sais pas
comment agir sur le code de retour du script PHP, quand il est
interprété ( ou compilé just in time ) par l'interpréteur PHP en mode CLI.
Merci beaucoup de ta réponse.
Amicalement.
Jean-Francois Ortolo
--
Visitez mon site gratuit donnant des Statistiques
et des Historiques Graphiques sur les Courses de Chevaux
http://www.ortolojf-courses.com
Pourquoi utiliser curl alors qu'un script php peut s'exécuter directement ? Si le script ne fait que des insertions/mises à jour/suppressions de données et aucun d'affichage, une tâche cron et hop ca roulaize, non ?
A vrai dire...
J'ai besoin que le script me rende quelque chose disant qu'il est allé jusqu'au bout sans problème.
Je fais çà en lui faisant afficher la chaîne: "OK" en fin de script.
Je me suis arrangé pour que le script Shell prenne automatiquement en compte l'absence ou la présence de cette chaîne rendue par le script, pour faire un traitement de reprise sur incident ( annulation des opérations sur bdd ) si cette chaîne n'est pas envoyée par le script.
Sinon, je sais pas comment le processus Shell de l'interpréteur PHP en mode CLI, pourrait rendre un numéro interprétable par le script Shell, en sortie du script PHP.
Je sais que quand on lance une commande dans un script Shell, la variable $? rend le code de retour de la commande. Mais je ne sais pas comment agir sur le code de retour du script PHP, quand il est interprété ( ou compilé just in time ) par l'interpréteur PHP en mode CLI.
Merci beaucoup de ta réponse.
Amicalement.
Jean-Francois Ortolo
-- Visitez mon site gratuit donnant des Statistiques et des Historiques Graphiques sur les Courses de Chevaux http://www.ortolojf-courses.com