OVH Community, votre nouvel espace communautaire.

Script PHP interrompu par OVH !


Michel74
20/06/2008, 07h00
Citation Envoyé par nellyinf
La commande d'appel ???
Il n'y a pas de commande d'appel dans mon script : on lance le script en allant sur la page ou il est contenu, et il se rappel lui même jusqu'a avoir vider le repertoire des fichier à traiter, c'est un dev perso que j'ai fait très basique.
Tu relances bien ton script après chaque traitement.
Comment fais-tu la liaison avec "document.location.href" ?

nellyinf
20/06/2008, 02h27
Citation Envoyé par sum_fvm
Ma question s'adressait à magic dreams
j'avais compris, je donnais seulement un exemple me concernant, son exemple est tout aussi valable

nellyinf
20/06/2008, 02h26
Citation Envoyé par Michel74
Merci Nellyinf,
Et quel est la commande d'appel ?
La commande d'appel ???
Il n'y a pas de commande d'appel dans mon script : on lance le script en allant sur la page ou il est contenu, et il se rappel lui même jusqu'a avoir vider le repertoire des fichier à traiter, c'est un dev perso que j'ai fait très basique.

sum_fvm
19/06/2008, 10h23
Citation Envoyé par nellyinf
Simplement car je ne sais dev qu'en php, mysql, html, javascript ....

Que en locale je n'ai absolument pas envie d'avoir un serveur apache / php / sql.

et que j'ai des dédiés qui passent leurs temps à glander.

Donc ça me permet d'automatiser tout ça en restant dans mes capacités actuelles et en exploitant les ressources matérielles dont je dispose (les serveurs que je loue).
Ma question s'adressait à magic dreams

Michel74
19/06/2008, 07h47
Citation Envoyé par nellyinf
cf le script si traitement de 30 photos par exemple :
Code:
Merci Nellyinf,
Et quel est la commande d'appel ?

nellyinf
19/06/2008, 05h01
Citation Envoyé par sum_fvm
Pourquoi ne pas faire cette action en local et uploader les miniatures ?
Simplement car je ne sais dev qu'en php, mysql, html, javascript ....

Que en locale je n'ai absolument pas envie d'avoir un serveur apache / php / sql.

et que j'ai des dédiés qui passent leurs temps à glander.

Donc ça me permet d'automatiser tout ça en restant dans mes capacités actuelles et en exploitant les ressources matérielles dont je dispose (les serveurs que je loue).

magic dreams
18/06/2008, 23h42
nellyinf,
Ta solution est au plus proche de ce que je cherche dans l'immédiat :
un auto refresh de script pour qu'il se termine jusqu'à ce que le traitement soit fait à 100% ! C'est excellent !
Bon, j'espère juste qu'OVH ne va pas détecter ma charge de script et me le blacklister Je verrai...

Par contre dans l'avenir, je ferai sûrement comme le préconise pprem car c'est toujours mieux de reporter les traitements lourds en traitement de page quand on peut ! Great !

Merci à tous pour vos contribs...

magic dreams
18/06/2008, 22h41
Merci pprem pour ta réponse. Ca me parle beaucoup ! Je vais tester pour voir si la génération dynamique des vignettes est suffisamment rapide.

nellyinf, je vais regarder ton source...merci

magic dreams
18/06/2008, 22h38
Parce qu'en local, je suis chez un client qui ne connait rien à l'info.
Et je n'ai pas acces à son poste non plus....
Le but est de tout gérer en ligne

sum_fvm
18/06/2008, 22h34
Citation Envoyé par magic dreams
merci pour vos reponses rapide

Je dois mettre à jour un site immo.
Je dois donc convertir à chaque mise à jour 600 images en miniatures :
C'est ça qui prend 1 minute (estimation). Sans compter les mises à jour de mes bases SQL - mais la c'est assez rapide)

Je procède ainsi : je balaye le dossier images et créee dynamiquement chaque image en miniature ds un autre dossier...
Pourquoi ne pas faire cette action en local et uploader les miniatures ?

nellyinf
18/06/2008, 20h03
cf le script si traitement de 30 photos par exemple :
Code:

Michel74
18/06/2008, 19h44
Et comment câble-t'on le refresh auto de la page ?

nellyinf
18/06/2008, 13h46
pour ton projet, tu peux peut être tiré quelques infos d'un script de traitement automatisé avec refresh auto de la page.

Je l'avait créé pour un traitement auto de plusieurs centaines / milliers d'image sur une gallerie phpwebgallery :
En gros j'uploadais les images dans un dossier par ftp et le script une fois lancé réduisait chaque images aux dimensions programmées, créé une miniature et copié le résultat dans les répertoires adéquates.
A adapter à ton cas biensur.

P.S : j'oubliais le lien
http://forum.phpwebgallery.net/viewtopic.php?id=12128

pprem
18/06/2008, 09h04
Hello

Si c'est le traitement de création des vignettes qu prend du temps, ne le fais pas... c'est pas plus compliqué que ça.

Lors de l'affichage des images, passe par un script plutôt que directement le GIF ou JPEG. Ce script pourrait retourner l'image au navigateur si le fichier existe et le créer à partir de la photo de départ si elle ne l'est pas. du coup tu gères comme ça un cache qui se met à jour tout seul en fonction de ce qui est consulté par les internautes et non ce qui est envoyé par tes fournisseurs d'annonces.

Déporter les taches lourdes (ou pas) sur des affichages de pages est souvent un bon moyen pour s'affranchir des limitations de durée sur des scripts très consommateurs.

Michel74
17/06/2008, 21h26
Citation Envoyé par magic dreams
En effet, Michel vient de m'indiquer une solution super efficace pour ce problème : regarder via le script ce qui reste à traiter et le gérer.
Merci, c'est effectivement une bonne solution !
Great !

magic dreams
17/06/2008, 18h03
Pour la RAM, oui Enycu, je savais qu'il y avait une limite (effectivement, j'ignore quelle valeur ?) mais, en tous les cas, comment expliquer que le traitement est fait à 100% une fois, puis la fois suivante (donc, le meme script, le meme traitement) il est interrompu avant ?!...Est-ce parce qu'on se partage tous la RAM d'un même serveur mutualisé (60GP pour mon cas) et que la ressource de 32Mo (par exemple) n'est pas 'réservée' et donc on peut se retrouver avec moins de RAM dispo à un instant T ?

En tous les cas puisqu'on ne peut pas se garantir un temps de traitement, il faut effectivement gérer la mise à jour comme le préconise Michel :

En effet, Michel vient de m'indiquer une solution super efficace pour ce problème : regarder via le script ce qui reste à traiter et le gérer.
Merci, c'est effectivement une bonne solution !

Merci pour votre aide !!!

Michel74
17/06/2008, 09h59
Suggestions :
- Il te faut UN SEUL script.
- Mettre dans script un test sur le traitements restants à effectuer et l'indiquer dans le résultat du script. S'il ne reste plus de traitements, le script répond qu'il n'y a rien à traiter.
- C'est la taille de tes fichiers images qui consomme les ressources UC et mémoire. Si tu as de très grandes images à traiter, ton script atteindra les limites plus rapidement.

enycu
17/06/2008, 03h06
Il y a aussi la taille mémoire occupée (mémoire ram) qui ne doit pas dépasser les 32 Mo je crois (selon les offres)
Tout ça pour dire que le travail d'un gros script occupe beaucoup de mémoire ram sur le serveur et cela est aussi limité. Il est possible que la limite ayant été atteinte, il stoppe l'exécution.

magic dreams
17/06/2008, 01h29
J'ai du nouveau : mauvaise nouvelle !!!

Je reviens sur la durée avant qu'un script ne soit interrompu par OVH.

Si en théorie on devrait voir tourner son script pendant 30 sec (60gp et 90Plan : voir phpinfo() max_execution_time), dans les faits, il n'en est rien !!!

Alors que je viens d'éclater ma mise à jour en 10 scripts qui traitent ma création de miniatures par étapes (script1 : 1 à 100 - script 2 : 101 à 200...), eh bien je constate que l'interruption se produit parfois à 12 secondes au lieu de 30 !!! Résultat ? Même mon découpage en scripts pourtant inférieur à 20 sec (c sur !) est finalement assez souvent interrompu un peu avant la fin !

Cela devient incacceptable de voir de telles variation de durée : car je ne sais plus sur quelle valeur "garantie" baser mon développement !

Je vais donc bientôt devoir faire 1 script par images pour ne pas être interrompu ?!

J'avoue être mécontent de ce constat car je dois encore redévelopper une n-ième fois une soluce pour contourner les anomalies des autres (OVH)...

Qui sait dire pourquoi cette durée est finalement :
  • pas respectée ?
  • aussi variable ?


Quelqu'un d'OVH peut répondre ? (je crois que je vais envoyer un incident à ce stade, car ce n'est pas normal...)

magic dreams
16/06/2008, 23h31
OK, merci beaucoup Michel !

Michel74
16/06/2008, 23h15
Citation Envoyé par magic dreams
Mais cela veut dire, lancer manuellement 10 scripts de 10 sec sequentiellement plutot que mon fameux update qui fait tout...
C'est bien cela que tu préconises ?
Oui.
Tes clients comprendrons très bien qu'il est nécessaire d'appuyer plusieurs fois sur un bouton jusqu'à ce qu'il n'y ait plus d'action à exécuter.

Citation Envoyé par magic dreams
Je ne pourrai pas envisager 1 bouton mise à jour qui lance tout (donc update.php) d'une traite si je comprends bien, sinon je retombe dans mon probleme mon bouton qui lance update qui lance scr1, scr2... ?
Non.

magic dreams
16/06/2008, 21h19
Rep à Michel74 :

oui, je suis parti sur cette piste justement.
Mais cela veut dire, lancer manuellement 10 scripts de 10 sec sequentiellement plutot que mon fameux update qui fait tout...
C'est bien cela que tu préconises ?

Je ne pourrai pas envisager 1 bouton mise à jour qui lance tout (donc update.php) d'une traite si je comprends bien, sinon je retombe dans mon probleme mon bouton qui lance update qui lance scr1, scr2... ?

Car je voulais faire un bouton de 'mise à jour' ergonomique pour des non-informaticiens, destiné à l'agence immo sur une page admin sécurisée par exemple....à cause de cette restriction OVH (que je comprends pour les charges serveur), ça devient délicat du coup...

A savoir pour ceux qui auraient pensé à la fonction SLEEP() : en créant 2 boucles "for" imbriquées avec un sleep dans la boucle mere qui découpe le traitement (la boucle fille contenant un traitement < 10sec), ca ne marche pas : sleep() ne change rien au problème : toujours interrompu (c'est logique mais bon)...j'ai testé au cas où ...)

magic dreams
16/06/2008, 21h15
Pour enycu :
Petite remarque : je viens de tester encore 2 fois chrono en main : le traitement s'est arrêté au bout de 20sec et 16 sec le suivant....donc pas 30s ?!? (pourtant sur 60gp : max_execution_time est bien à 30 sec)
D'ailleurs, ça montre une variation (charge du serveur fluctuante surement ?...)

ps : super la rubrique sécurité - merci pour cette super contrib !!!)

Michel74
16/06/2008, 21h08
Pourquoi, après le transfert FTP, ne pas prévoir un script PHP à exécuter avec un navigateur qui ferait ces opérations de conversion d'image et de mise à jours de la base de données.
Ce script serait limité au traitement de N biens immobiliers.
Ce script serait répété X fois jusqu'au traitement de tous les biens immobiliers.

magic dreams
16/06/2008, 21h07
Pour être complet sur le genre d'action :
je lance un update.php qui contient tous les scripts (includes) qui servent à ma mise à jour :
  • 1 php qui dezippe les donnees
  • 1 php qui archive mes tables
  • 1 php qui archive mes fichiers
  • 1 php qui parse le xml et l'ecrit dans mysql
  • 1 php qui cree les images miniatures
  • 1 php orienté admin (mail, log...)


c'est le php "miniature" le plus long en traitement.

Voila, la je suis complet en info

magic dreams
16/06/2008, 20h55
Pour Michel74 : ce n'est pas une mise à jour journaliere. C'est en fonction de l'envoi des donnees de l'agence en ftp sur le site (xml + images) que je traite en php et mysql. Ce sera plutot d'ordre hebdomadaire.

magic dreams
16/06/2008, 20h48
merci pour vos reponses rapide

Je dois mettre à jour un site immo.
Je dois donc convertir à chaque mise à jour 600 images en miniatures :
C'est ça qui prend 1 minute (estimation). Sans compter les mises à jour de mes bases SQL - mais la c'est assez rapide)

Je procède ainsi : je balaye le dossier images et créee dynamiquement chaque image en miniature ds un autre dossier...

Michel74
16/06/2008, 19h44
Quel genre d'action effectues-tu :
- Mise à jour de scripts ?
- Mise à jour de tables de bases de données ?

Pourquoi une telle mise à jour journalière ?

enycu
16/06/2008, 19h40
Non, c'est 30s en vrai. C'est marqué dans le phpinfo dans "max_execution_time".
http://90plan.ovh.net/test.php5 (remplace 90plan par 60gp, start1G, ou le nom de ton offre).

magic dreams
16/06/2008, 19h05
Bonjour à tous les développeurs !

Un sujet jamais abordé ici...

Savez vous qu'OVH interrompt des script PHP qui durent plus de 15 secondes ? ?

(oui c'est dans les CGV mais quand même, un petit message du genre : "votre script a été interrompu par nos services car son temps de traitement est > à 15 sec" aurait été du bon sens et du respect pour le client aussi....car on cherche l'erreur dans notre code avant de penser à une restriction OVH...


=>> Or, mon script PHP s'executerait integralement en 1 minute env. Donc il est coupé en pleine execution !!

Bin, je ne sais plus comment faire du coup......

J'ai bien pensé à une solution CRON qui lancerait script1.php à 0h00, puis script2.php à 0h01; puis script3.php à 0H02, mais ça retarde d'autant la disponibilité intègre en terme de contenu du site (et je comptais pas gérer un affichage type "désolé, site en maintenance"...je n'ai plus trop le temps

Comment faites vous ou comment feriez vous ?? ?

Actuellement, je faisais comme ça : je lancais 'update.php' qui faisait d'une traite ma mise à jour en lancant (via des includes) script1, script2, script3... (donc 1 minute de traitement estimé) : mais OVH voit 1 seul script, je crois (update.php) qui dure trop longtemps puisqu'ils l'interrompent SANS M'AVERTIR ! ...pfff ! Pas cool ça !

Quelqu'un aurait-il une solution sans passer par le CRON, donc en pur PHP ???

Donc autrement dit, comment eclater un traitement de 1 minute ou + en x traitements de 10 secondes et comment le lancer integralement surtout sans etre interrompu ?

CRON incontournable ou pas ???? (car à la base, j'ai qu'un acces FTP, et pas de compte technique ou adm OVH pour ce site, donc idealement je cherche à eviter CRON)