Fonctionnement different suivant la dure e d'un script

[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 ?

[John GALLET]

Bonjour,

Post by Alain BARTHE
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...

Post by Alain BARTHE
En fonction des paramètres saisis dans le formulaire, le calcul peut
durer de quelques secondes à plusieurs minutes.

Peut-on le "deviner" à l'avance ?

Post by Alain BARTHE
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]

Post by Alain BARTHE
Bonjour,

Post by Alain BARTHE
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...

Post by Alain BARTHE
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...

Post by Alain BARTHE

Post by Alain BARTHE
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...

Post by Alain BARTHE
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]

Post by Alain BARTHE
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 !

Post by Alain BARTHE
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]

Post by Alain BARTHE
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).