Fonctionnement different suivant la dure e d'un script
4 réponses
Alain BARTHE
Bonjour,
Je souhaite lancer, au travers d'un formulaire, un programme de calcul
dont je ne maitrise pas le comportement.
En fonction des paramètres saisis dans le formulaire, le calcul peut
durer de quelques secondes à plusieurs minutes.
J'aimerais dans le premier cas (< 10 s par exemple) afficher directement
une page de résultat, et sinon envoyer un mail à l'utilisateur avec
l'URL ou retrouver les résultats dès qu'il est terminé.
Je suppose qu'il faut passer par un système de time-out, mais je ne sais
pas trop comment procéder.
Pourriez-vous SVP m'orienter vers quelques pistes ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
John GALLET
Bonjour,
Je souhaite lancer, au travers d'un formulaire, un programme de calcul dont je ne maitrise pas le comportement.
C'est souvent le cas. Rien qu'un appel xml-rpc...
En fonction des paramètres saisis dans le formulaire, le calcul peut durer de quelques secondes à plusieurs minutes.
Peut-on le "deviner" à l'avance ?
Je suppose qu'il faut passer par un système de time-out, mais je ne sais pas trop comment procéder. Pourriez-vous SVP m'orienter vers quelques pistes ?
Solution 1: dans tous les cas, tu renvoies vers une page qui affichera "un jour" les résultats, même s'il est immédiat.
Solution 2: tu veux attendre le résultat exactement X secondes au maximum avant de laisser tourner en background. Il est difficile de te répondre sans savoir quelle est l'interface que tu utilises pour appeler le calcul externe. Socket ? Ligne de commande unix ? http/xml-rpc ?
a++; JGA
Bonjour,
Je souhaite lancer, au travers d'un formulaire, un programme de calcul
dont je ne maitrise pas le comportement.
C'est souvent le cas. Rien qu'un appel xml-rpc...
En fonction des paramètres saisis dans le formulaire, le calcul peut
durer de quelques secondes à plusieurs minutes.
Peut-on le "deviner" à l'avance ?
Je suppose qu'il faut passer par un système de time-out, mais je ne sais
pas trop comment procéder.
Pourriez-vous SVP m'orienter vers quelques pistes ?
Solution 1: dans tous les cas, tu renvoies vers une page qui affichera
"un jour" les résultats, même s'il est immédiat.
Solution 2: tu veux attendre le résultat exactement X secondes au
maximum avant de laisser tourner en background. Il est difficile de te
répondre sans savoir quelle est l'interface que tu utilises pour appeler
le calcul externe. Socket ? Ligne de commande unix ? http/xml-rpc ?
Je souhaite lancer, au travers d'un formulaire, un programme de calcul dont je ne maitrise pas le comportement.
C'est souvent le cas. Rien qu'un appel xml-rpc...
En fonction des paramètres saisis dans le formulaire, le calcul peut durer de quelques secondes à plusieurs minutes.
Peut-on le "deviner" à l'avance ?
Je suppose qu'il faut passer par un système de time-out, mais je ne sais pas trop comment procéder. Pourriez-vous SVP m'orienter vers quelques pistes ?
Solution 1: dans tous les cas, tu renvoies vers une page qui affichera "un jour" les résultats, même s'il est immédiat.
Solution 2: tu veux attendre le résultat exactement X secondes au maximum avant de laisser tourner en background. Il est difficile de te répondre sans savoir quelle est l'interface que tu utilises pour appeler le calcul externe. Socket ? Ligne de commande unix ? http/xml-rpc ?
a++; JGA
Alain BARTHE
John GALLET a écrit :
Bonjour,
Je souhaite lancer, au travers d'un formulaire, un programme de calcul dont je ne maitrise pas le comportement.
C'est souvent le cas. Rien qu'un appel xml-rpc...
En fonction des paramètres saisis dans le formulaire, le calcul peut durer de quelques secondes à plusieurs minutes.
Peut-on le "deviner" à l'avance ?
On doit pouvoir, de manière empirique, mais comme il y a pas mal de variables qui peuvent influer sur le comportement, c'est difficile à dire à priori.
De même que la patience de l'utilisateur en face de son écran...
Je suppose qu'il faut passer par un système de time-out, mais je ne sais pas trop comment procéder. Pourriez-vous SVP m'orienter vers quelques pistes ?
Solution 1: dans tous les cas, tu renvoies vers une page qui affichera "un jour" les résultats, même s'il est immédiat.
Solution 2: tu veux attendre le résultat exactement X secondes au maximum avant de laisser tourner en background. Il est difficile de te répondre sans savoir quelle est l'interface que tu utilises pour appeler le calcul externe. Socket ? Ligne de commande unix ? http/xml-rpc ?
Je ne sais pas trop encore : mon formulaire doit permettre de saisir des valeurs, qui serviront ensuite à générer un fichier texte, mis en entrée d'un programme de calcul écrit en Fortran.
Comme le soft peut s'installer sur la même machine, je pensais le lancer avec une commande Linux (de type spawn ou exec par exemple).
Plus tard, le soft sera peut-être exécuté sur une machine différente, plus rapide par exemple, si besoin est.
Je suis en phase de prototypage...
a++; JGA
John GALLET a écrit :
Bonjour,
Je souhaite lancer, au travers d'un formulaire, un programme de calcul
dont je ne maitrise pas le comportement.
C'est souvent le cas. Rien qu'un appel xml-rpc...
En fonction des paramètres saisis dans le formulaire, le calcul peut
durer de quelques secondes à plusieurs minutes.
Peut-on le "deviner" à l'avance ?
On doit pouvoir, de manière empirique, mais comme il y a pas mal de
variables qui peuvent influer sur le comportement, c'est difficile à
dire à priori.
De même que la patience de l'utilisateur en face de son écran...
Je suppose qu'il faut passer par un système de time-out, mais je ne
sais pas trop comment procéder.
Pourriez-vous SVP m'orienter vers quelques pistes ?
Solution 1: dans tous les cas, tu renvoies vers une page qui affichera
"un jour" les résultats, même s'il est immédiat.
Solution 2: tu veux attendre le résultat exactement X secondes au
maximum avant de laisser tourner en background. Il est difficile de te
répondre sans savoir quelle est l'interface que tu utilises pour appeler
le calcul externe. Socket ? Ligne de commande unix ? http/xml-rpc ?
Je ne sais pas trop encore : mon formulaire doit permettre de saisir des
valeurs, qui serviront ensuite à générer un fichier texte, mis en entrée
d'un programme de calcul écrit en Fortran.
Comme le soft peut s'installer sur la même machine, je pensais le lancer
avec une commande Linux (de type spawn ou exec par exemple).
Plus tard, le soft sera peut-être exécuté sur une machine différente,
plus rapide par exemple, si besoin est.
Je souhaite lancer, au travers d'un formulaire, un programme de calcul dont je ne maitrise pas le comportement.
C'est souvent le cas. Rien qu'un appel xml-rpc...
En fonction des paramètres saisis dans le formulaire, le calcul peut durer de quelques secondes à plusieurs minutes.
Peut-on le "deviner" à l'avance ?
On doit pouvoir, de manière empirique, mais comme il y a pas mal de variables qui peuvent influer sur le comportement, c'est difficile à dire à priori.
De même que la patience de l'utilisateur en face de son écran...
Je suppose qu'il faut passer par un système de time-out, mais je ne sais pas trop comment procéder. Pourriez-vous SVP m'orienter vers quelques pistes ?
Solution 1: dans tous les cas, tu renvoies vers une page qui affichera "un jour" les résultats, même s'il est immédiat.
Solution 2: tu veux attendre le résultat exactement X secondes au maximum avant de laisser tourner en background. Il est difficile de te répondre sans savoir quelle est l'interface que tu utilises pour appeler le calcul externe. Socket ? Ligne de commande unix ? http/xml-rpc ?
Je ne sais pas trop encore : mon formulaire doit permettre de saisir des valeurs, qui serviront ensuite à générer un fichier texte, mis en entrée d'un programme de calcul écrit en Fortran.
Comme le soft peut s'installer sur la même machine, je pensais le lancer avec une commande Linux (de type spawn ou exec par exemple).
Plus tard, le soft sera peut-être exécuté sur une machine différente, plus rapide par exemple, si besoin est.
Je suis en phase de prototypage...
a++; JGA
John GALLET
Re,
[NB: pas moyen d'avoir deux formattages identiques dans deux posts d'affilée, désolé si le wrapping à 72 chars ne passe pas]
On doit pouvoir, de manière empirique, mais comme il y a pas mal de variables qui peuvent influer sur le comportement, c'est difficile à dire à priori.
De même que la patience de l'utilisateur en face de son écran...
Facile: inexistante ;-) C'est pour hier !
Comme le soft peut s'installer sur la même machine, je pensais le lancer avec une commande Linux (de type spawn ou exec par exemple). Plus tard, le soft sera peut-être exécuté sur une machine différente, plus rapide par exemple, si besoin est.
Tant que tu peux, d'une manière ou d'une autre (je n'aime pas les remote shell, mais dans certains cas, c'est pratique), lancer une tâche unix en background, tu peux te faciliter la vie de cette manière là, en ayant bien entendu des noms uniques pour les fichiers d'entrée et pour la récupération de la sortie.
http://faqfclphp.free.fr/#rub4.2
Dans tous les cas, qui dit background dit potentiellement difficultés de détection de la fin correcte ou non: si ça se gaufre, tu n'auras jamais ni le résultat ni même peut-être l'erreur, ça dépend du programme.
Tu acceptes de faire du polling actif du résultat pendant "un certain temps", si le fichier de résultat arrive avant, tu renvoies le résultat en direct à l'utilisateur, sinon, tu envoies un moyen de récupération asynchrone à déterminer. A voir si tu peux tout de suite afficher "un jour le résultat sera là, faites du refresh de temps en temps" ou si tu dois dire "vous recevrez un mail qui vous indiquera où est le résultat dès que c'est cuit", en particulier en termes de sécurité d'accès entre utilisateurs.
Peut-être qu'il faudra garder une liste de requêtes pending et vérifier par ailleurs leur complétion pour envoyer la bonne information à la bonne personne et limiter le nombre de requêtes en cours par utilisateur pour éviter les excités du F5 qui t'écroulent un système complet en empilant 50 fois la même demande...
Tu peux également encapsuler l'appel sur une machine locale ou distante par du http (simple ou xml/soap) qui reste synchrone avec un time out dans le client. En sortie tu n'as qu'à tester le résultat (reçu ou time out).
Dans les deux cas, le loadbalancing sur plusieurs machines exécutant le programme fortran est possible (pour autant que le goulet d'étranglement ne soit pas plus loin).
HTH JGA
Re,
[NB: pas moyen d'avoir deux formattages identiques dans deux posts
d'affilée, désolé si le wrapping à 72 chars ne passe pas]
On doit pouvoir, de manière empirique, mais comme il y a pas mal de
variables qui peuvent influer sur le comportement, c'est difficile à
dire à priori.
De même que la patience de l'utilisateur en face de son écran...
Facile: inexistante ;-) C'est pour hier !
Comme le soft peut s'installer sur la même machine, je pensais le lancer
avec une commande Linux (de type spawn ou exec par exemple).
Plus tard, le soft sera peut-être exécuté sur une machine différente,
plus rapide par exemple, si besoin est.
Tant que tu peux, d'une manière ou d'une autre (je n'aime pas les remote
shell, mais dans certains cas, c'est pratique), lancer une tâche unix en
background, tu peux te faciliter la vie de cette manière là, en ayant
bien entendu des noms uniques pour les fichiers d'entrée et pour la
récupération de la sortie.
http://faqfclphp.free.fr/#rub4.2
Dans tous les cas, qui dit background dit potentiellement difficultés de
détection de la fin correcte ou non: si ça se gaufre, tu n'auras jamais
ni le résultat ni même peut-être l'erreur, ça dépend du programme.
Tu acceptes de faire du polling actif du résultat pendant "un certain
temps", si le fichier de résultat arrive avant, tu renvoies le résultat
en direct à l'utilisateur, sinon, tu envoies un moyen de récupération
asynchrone à déterminer. A voir si tu peux tout de suite afficher "un
jour le résultat sera là, faites du refresh de temps en temps" ou si tu
dois dire "vous recevrez un mail qui vous indiquera où est le résultat
dès que c'est cuit", en particulier en termes de sécurité d'accès entre
utilisateurs.
Peut-être qu'il faudra garder une liste de requêtes pending et vérifier
par ailleurs leur complétion pour envoyer la bonne information à la
bonne personne et limiter le nombre de requêtes en cours par utilisateur
pour éviter les excités du F5 qui t'écroulent un système complet en
empilant 50 fois la même demande...
Tu peux également encapsuler l'appel sur une machine locale ou distante
par du http (simple ou xml/soap) qui reste synchrone avec un time out
dans le client. En sortie tu n'as qu'à tester le résultat (reçu ou time
out).
Dans les deux cas, le loadbalancing sur plusieurs machines exécutant le
programme fortran est possible (pour autant que le goulet d'étranglement
ne soit pas plus loin).
[NB: pas moyen d'avoir deux formattages identiques dans deux posts d'affilée, désolé si le wrapping à 72 chars ne passe pas]
On doit pouvoir, de manière empirique, mais comme il y a pas mal de variables qui peuvent influer sur le comportement, c'est difficile à dire à priori.
De même que la patience de l'utilisateur en face de son écran...
Facile: inexistante ;-) C'est pour hier !
Comme le soft peut s'installer sur la même machine, je pensais le lancer avec une commande Linux (de type spawn ou exec par exemple). Plus tard, le soft sera peut-être exécuté sur une machine différente, plus rapide par exemple, si besoin est.
Tant que tu peux, d'une manière ou d'une autre (je n'aime pas les remote shell, mais dans certains cas, c'est pratique), lancer une tâche unix en background, tu peux te faciliter la vie de cette manière là, en ayant bien entendu des noms uniques pour les fichiers d'entrée et pour la récupération de la sortie.
http://faqfclphp.free.fr/#rub4.2
Dans tous les cas, qui dit background dit potentiellement difficultés de détection de la fin correcte ou non: si ça se gaufre, tu n'auras jamais ni le résultat ni même peut-être l'erreur, ça dépend du programme.
Tu acceptes de faire du polling actif du résultat pendant "un certain temps", si le fichier de résultat arrive avant, tu renvoies le résultat en direct à l'utilisateur, sinon, tu envoies un moyen de récupération asynchrone à déterminer. A voir si tu peux tout de suite afficher "un jour le résultat sera là, faites du refresh de temps en temps" ou si tu dois dire "vous recevrez un mail qui vous indiquera où est le résultat dès que c'est cuit", en particulier en termes de sécurité d'accès entre utilisateurs.
Peut-être qu'il faudra garder une liste de requêtes pending et vérifier par ailleurs leur complétion pour envoyer la bonne information à la bonne personne et limiter le nombre de requêtes en cours par utilisateur pour éviter les excités du F5 qui t'écroulent un système complet en empilant 50 fois la même demande...
Tu peux également encapsuler l'appel sur une machine locale ou distante par du http (simple ou xml/soap) qui reste synchrone avec un time out dans le client. En sortie tu n'as qu'à tester le résultat (reçu ou time out).
Dans les deux cas, le loadbalancing sur plusieurs machines exécutant le programme fortran est possible (pour autant que le goulet d'étranglement ne soit pas plus loin).
HTH JGA
Mickael Wolff
Le 13/08/2010 21:28, Alain BARTHE a écrit :
Je suis en phase de prototypage...
Je verrais ça de la manière suivante. Le formulaire permet de saisir une tâche à accomplir, tâche consignée dans un journal (une table en base, par exemple). Une fois l'enregitrement de la requête, tu transfert sur une page d'observation de l'état d'avancement. Sur cette page, le client peut éventuellement télécharger le fichier généré s'il est disponible. S'il n'est pas disponible, l'utilisateur peut jouer les cliqueurs fous. Mais il y a peut-être plus astucieux, voir deux trois chapitres plus bas.
Un cron s'occupe de scanner régulièrement cette table et répartie lance les tâches. Ou, si tu as des utilisateurs pressés, tu as un daemon à qui tu peux envoyer un message (là tu as le choix, touch un fichier, socket, e-mail, etc).
Le démon (ou le cron qui a lancé) doit surveiller les (ou le) processus, et mettre à jour la base de données en conséquence (dans une table en base « tâches en court » par exemple). Pour que les utilisateurs puissent consulter l'état d'avancement de leur tâche. Voir peuvent forcer, rééditer le travail, requérir la priorité, relancer, etc Je suis certain qu'ils vont te demander de telles fonctionnalités ;)
Vu que le programme peut prendre son temps, on ne va pas exiger du client qu'il attende comme un con devant son écran. Il a déjà une application qui fait ça : le client de messagerie électronique (instantanée ou asynchrone). Une fois que le programme fortran a terminé sa tâche, le démon stocke le fichier et envoie le résultat au commanditaire. Il peut aussi envoyer le fichier directement (compressé ou non), suivant la politique informatique de la société.
Le démon peut être en PHP, même si je le déconseille (je n'ai pas de bon retour sur le bricolage à base de ticks). Un daemon en python ou perl est peut-être à envisager. Voir suivre la mode et le faire en Javascript :D (Node.js).
Je verrais ça de la manière suivante. Le formulaire permet de saisir
une tâche à accomplir, tâche consignée dans un journal (une table en
base, par exemple). Une fois l'enregitrement de la requête, tu transfert
sur une page d'observation de l'état d'avancement. Sur cette page, le
client peut éventuellement télécharger le fichier généré s'il est
disponible. S'il n'est pas disponible, l'utilisateur peut jouer les
cliqueurs fous. Mais il y a peut-être plus astucieux, voir deux trois
chapitres plus bas.
Un cron s'occupe de scanner régulièrement cette table et répartie
lance les tâches.
Ou, si tu as des utilisateurs pressés, tu as un daemon à qui tu peux
envoyer un message (là tu as le choix, touch un fichier, socket, e-mail,
etc).
Le démon (ou le cron qui a lancé) doit surveiller les (ou le)
processus, et mettre à jour la base de données en conséquence (dans une
table en base « tâches en court » par exemple). Pour que les
utilisateurs puissent consulter l'état d'avancement de leur tâche. Voir
peuvent forcer, rééditer le travail, requérir la priorité, relancer, etc
Je suis certain qu'ils vont te demander de telles fonctionnalités ;)
Vu que le programme peut prendre son temps, on ne va pas exiger du
client qu'il attende comme un con devant son écran. Il a déjà une
application qui fait ça : le client de messagerie électronique
(instantanée ou asynchrone).
Une fois que le programme fortran a terminé sa tâche, le démon stocke
le fichier et envoie le résultat au commanditaire. Il peut aussi envoyer
le fichier directement (compressé ou non), suivant la politique
informatique de la société.
Le démon peut être en PHP, même si je le déconseille (je n'ai pas de
bon retour sur le bricolage à base de ticks). Un daemon en python ou
perl est peut-être à envisager. Voir suivre la mode et le faire en
Javascript :D (Node.js).
Je verrais ça de la manière suivante. Le formulaire permet de saisir une tâche à accomplir, tâche consignée dans un journal (une table en base, par exemple). Une fois l'enregitrement de la requête, tu transfert sur une page d'observation de l'état d'avancement. Sur cette page, le client peut éventuellement télécharger le fichier généré s'il est disponible. S'il n'est pas disponible, l'utilisateur peut jouer les cliqueurs fous. Mais il y a peut-être plus astucieux, voir deux trois chapitres plus bas.
Un cron s'occupe de scanner régulièrement cette table et répartie lance les tâches. Ou, si tu as des utilisateurs pressés, tu as un daemon à qui tu peux envoyer un message (là tu as le choix, touch un fichier, socket, e-mail, etc).
Le démon (ou le cron qui a lancé) doit surveiller les (ou le) processus, et mettre à jour la base de données en conséquence (dans une table en base « tâches en court » par exemple). Pour que les utilisateurs puissent consulter l'état d'avancement de leur tâche. Voir peuvent forcer, rééditer le travail, requérir la priorité, relancer, etc Je suis certain qu'ils vont te demander de telles fonctionnalités ;)
Vu que le programme peut prendre son temps, on ne va pas exiger du client qu'il attende comme un con devant son écran. Il a déjà une application qui fait ça : le client de messagerie électronique (instantanée ou asynchrone). Une fois que le programme fortran a terminé sa tâche, le démon stocke le fichier et envoie le résultat au commanditaire. Il peut aussi envoyer le fichier directement (compressé ou non), suivant la politique informatique de la société.
Le démon peut être en PHP, même si je le déconseille (je n'ai pas de bon retour sur le bricolage à base de ticks). Un daemon en python ou perl est peut-être à envisager. Voir suivre la mode et le faire en Javascript :D (Node.js).
