Discussion :

[ganguill]

Bonjour,

j'ai cherché des tas de trucs sur internet, mais rien trouvé de très bon

Alors voila, je possède un script PHP qui appel un petit logiciel (Sql*Loader). Ce petit logiciel charge des données dans une table d'une base de données.

Le problème c'est que les chargements sont très longs (tout à fait normal)! Mais en attendant mon script PHP tourne, et au bout d'une heure exactement, ma page internet affiche "the page cannot be displayed"...

Au départ mes scripts se coupaient au bout de 30 seconde! J'avais donc modifié le temps avec set_time_limit(3600), et donc ça tournait très bien pendant une heure! Maintenant je me rend compte qu'une heure est trop juste, mais il ne se passe même plus rien quand je modifie le set_time_limit.. Même en le repassant à 30 secondes la page ne se bloque plus quand j'exécute une longue requête..

J'aurais voulu modifier ce bug pour que le script continue de tourner pendant 10 ou 20 heures... (c'est ce que j'aurais idéalement besoin)

Une solution? Merci à tous

[kabkab]

Bonjour,
Si tu mets

Code php :

Sélectionner tout - Visualiser dans une fenêtre à part

set_time_limit(0);

ton script se déroulera indéfiniment jusqu'à son exécution finale. Il ne faut pas oublier la charge qu'il va générer sur ton serveur.
Mais l'idéal et c'est ce que je fais pour mes scripts c'est de faire rouler le script en parties. Je m'explique si je dois remplir 10.000 enregistrements, je crée un champ qui va contenir un sorte de compteur, je rempli ma table avec des portions de 200 enregistrements et je mets à jour mon compteur pour qu'à mon prochain lancement il consulte ce compteur et commence à cette valeur avec 200 enregistrements et ainsi de suite.

[ganguill]

Merci pour cette réponse
Pour la charge du serveur tu parles du serveur php ou celui de ma base de données (Oracle) ?

Pour ce qui est de découper je voudrai bien, mais comment? Car ici ma table à charger va contenir 11millions d'enregistrements environ. Donc admettons que je charge 1million d'enregistrements, comment indiquer à php de se relancer? Le problème pour moi n'est pas de repartir à l'enregistrement 1000001, mais c'est de dire à PHP comment se relancer..

Je ne vais pas vous balancer mon code, ça serai beaucoup trop long.. En gros voilà ce qu'il se passe :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
1 - l'utilisateur clique sur un bouton "parcourir", et recherche le fichier de données à insérer dans la table
2 - PHP créé les fichiers de configurations d'Sql*Loader
3 - Sql*Loader est appelé par PHP, et charge le fichier qu'a indiqué l'utilisateur. A partir de ce moment, le chargement commence et prend environ 1-2h.

Le problème c'est que je ne suis pas sûr que ce rechargement de page soit dû au temps d'exécution.. En effet, même en ayant changé dans le php.ini la valeur du max_exec_time(36000), la page me sort un "The page cannot be displayed" au bout d'1 heure exactement C'est bizarre quand même...

[kabkab]

Bonjour,
En ce qui concerne la charge du serveur, je parle de tous les serveurs qui vont traiter ton script.
11 millions... Je ne sais quoi dire!
Expliques un peu ce que tu compte faire. D'où proviennent les données que tu veux envoyer? Est-ce d'une base vers une autre? Là c'est sutout de la curiosité qui me fait poser ces questions. 11 millions...

[RunCodePhp]

Salut

J'ai le même sentiment que Kabkab ... 1 million d'enregistrements ???
Puis faire tourner un script Php en continue pendant 10 ou 20 heures ???

Je veux bien admettre qu'il y a des cas particuliers, mais là, j'ai plutôt l'impression qu'il y a un problème sur le choix ou la manière de faire, non ?
Là, on a l'impression que tu utilise une trottinette alors qu'il y a au moins 30 bornes à faire quotidiennement.

Utiliser du tout Php dans ce cas là me semble pas adapté.
Au lieu d'utiliser Php pour requêter, pourquoi ne pas le faire directement via le système ? (par exemple)

Puis charger un fichier via un bouton "parcourir", donc tout ça via HTTP, est ce réellement la meilleur technique ?
L'intervention humaine est elle vraiment nécessaire dans un cas pareil ?
N'y a t-il pas moyen de mettre les machines en réseau, et de le faire via un cron (par exemple), tous ça via des commandes systèmes.
Etc, etc ...

En tout cas, faire un backup via une commande système prend quelque secondes, quelques minutes tout au plus, même pour 1 million de lignes, alors qu'en le faisant en boucle via Php ça prends des plombes.

Bref, pas sûr que les bons outils soient utilisés dans un cas pareil.

[ganguill]

Bonjour
Tout d'abord merci à tous pour ces remarques

Alors oui 11 millions d'enregistrements (et encore, ce n'est qu'une table (il y en a 3 en tout qui sont relativement conséquentes). Ces données proviennent des réseaux de France Telecom. Ce sont donc des fichiers .txt de données brutes (contenant des séparateurs), qu'il faut insérer dans des tables sur un serveur Oracle. Ces fichiers sont assez importants (un peu moins de 4Go).

Pour cela il n'y a pas 36 façons de les charger dans la base de données, mais 2 (Sql*Loader, ou des tables externes). Mon programme PHP appelle donc Sql*Loader via une ligne de commande (ce n'est pas PHP qui bosse, mais bien Sql*Loader). Simplement la page web reste "figée" tant que Sql*Loader n'a pas fini (que j'importe les données directement par l'invite de commande DOS avec un appel à Sql*Loader, ou bien par l'application, le résultat est le même niveau temps de chargement).

Les requêtes en elles-mêmes sont assez longues à exécuter (environ 5 minutes, parfois moins). En même temps les infos sont recherchées entre plusieurs tables de plusieurs millions de lignes, et le nombre de résultat est parfois important..!

Enfin, pour ce qui est du bouton "parcourir", je ne récupère ainsi que le chemin du fichier qui apparaît dans la zone de texte Je n'upload rien du tout! Je récupère juste ce chemin afin de créer les fichiers de configuration d'Sql*Loader (ces fichiers ont besoin du chemin du fichier de données)

Voilà, j'espère vous avoir correctement répondu

[RunCodePhp]

Je ne pige pas un truc.

Ce que je comprends, c'est que tu utilise une interface Web juste pour que quelqu'un désigne un fichier, qui plus est, ce trouve sur la machine.
Donc le fichier est là, il a bien été créé à un moment donné non ?
Puis apparemment ce n'est pas quelqu'un qui l'a déposé vu que tu dis qu'il n'y a pas eu d'upload.

Pourquoi ne pas chercher une commande système qui elle s'occuperait automatiquement à rechercher ce fichier ?
A mon sens, si ce n'est pas une personne qui dépose le fichier, c'est qu'il a été créé, déposé par quelque chose et pas n'importe où, non ?
Donc ça veut dire qu'il doit avoir moyen autre qu'une manip humaine pour le retrouver, genre une commande système qui dirait : Un nouveau fichier est créé dans ce répertoire -> hop, on lance le backup


Ou alors, je ne sais pas, mais admettons qu'il faille une intervention humaine, et bien on peu très bien imaginer qu'une fois désigné le fichier en question, se contenter de mettre à jour un fichier (genre mettre le nom du fichier à exécuter, qui prend 1 seconde) c'est tout, donc une réponse (un simple Ok) se fera dans la seconde.
Ensuite, une commande système se chargerait de lire ce fichier, d'en récupérer le nom et de l'exécuter.
Bref, j'en sais rien.


En tout cas, j'ai l'impression que ton problème c'est que dès que tu exécute le backup en Php, il faut attendre la fin du traitement pour que Php retourne une réponse, c'est ça ?
Si c'est ça, il ne faudrait pas que ce soit directement Php qui déclencherait ce traitement, mais le système, non ?

[ganguill]

Alors en fait ce fichier .txt est disponible au téléchargement sur le réseau de France Telecom! Tous les jours il y en a un nouveau de disponible, mais on ne le télécharge par exemple qu'une fois par semaine!
Les informations qu'il contient sont donc différentes selon la date du fichier.

On peut choisir également de faire des traitements sur le fichier du 15 mai par exemple, et ceci pendant 10 jours! Voilà pourquoi on essaye de télécharger régulièrement les fichiers sur l'ordinateur (afin de pouvoir les utiliser plus tard), mais on ne les charge pas forcément tout de suite après le téléchargement !

Je ne peux donc pas faire de programme automatique qui s'occuperai de charger ces nouvelles données à chaque fois qu'elles sont disponibles sur l'ordinateur (enfin si je pourrais, mais je ne veux pas). Tout simplement car je peux très bien utiliser le même fichier pour une période indéterminée

En tout cas, j'ai l'impression que ton problème c'est que dès que tu exécute le backup en Php, il faut attendre la fin du traitement pour que Php retourne une réponse, c'est ça ?
Si c'est ça, il ne faudrait pas que ce soit directement Php qui déclencherait ce traitement, mais le système, non ?

Oui c'est tout à fait ça! Mais l'idée c'est aussi de permettre à n'importe quel utilisateur de charger ces données quand il le souhaite, en ne passant pas par 36 applications différentes! Par exemple il peut très bien demander de charger ces nouvelles données la nuit, afin d'avoir des tables contenant de nouvelles données à traiter le lendemain matin (traitements qu'il fera avec cette même application).

[SpaceInvader]

Salut,

Je reviens sur une piste qui à déjà été évoquée :

Imaginons :
->ton utilisateur choisi le fichier & la date de traitement.
->Avec ces informations du génère un script php qui réalise .txt vers BDD
->Tu créer un Cron (Si t'es sur Linux) sinon une tâches planifiée qui va exécuter un bat ou équivalent à la date choisie.

Le bat aurait cette tête là :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
php -f "path/vers/ton/script.php"

Et la tu n'a pas de sortie Web, pas de temps limite d'exécution.

Je ne sait pas si j'ai cerné toutes les problématiques, mais d'après ce que j'ai compris je ferais comme cela.

SpaceInvader.

[ganguill]

SpaceInvader => Effectivement c'est une solution qui fonctionnerait.. ce n'est plus PHP mais la tâche planifié qui appellerai le .bat..
Mais au final ça reviendrait un peu au même... J'aurais la main sur l'application mais je ne pourrais rien faire avec, étant donné que les tables seront en train de charger, et que donc ces données ne seront pas accessibles pour effectuer des traitements dessus.

Je résolverai simplement ce problème de temps d'exécution.. Mais j'aimerai autant que mon navigateur puisse tout faire (je répète qu'au final je ne gagne rien en passant par mon application PHP (qui se charge juste d'appeller le .bat) ou en passant directement par l'invite de commande DOS)...

Donc il me faudrait juste trouver comment ne pas couper mon navigateur au bout d'une heure. D'ailleurs je pense avoir une piste : dans mon phpinfo j'obtiens ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
max_execution_time : Local value(3600), Master value(36000)

Quand j'ai changé max_execution_time dans le php.ini en le faisant passer à 36000, c'est le Master Value qui a changé! J'en conclue que c'est le Local Value qui est utilisé quand même.. Comment changer ce Local Value?

Merci à tous

[RunCodePhp]

Tout à fait SpaceInvader, faut que se soit le système qui gère les backup, pas Php, pas l'application Web.

L'application Web doit se contenter d'uploader sur FT, et ensuite enregitrer quelque part ce qu'il doit être fait avec ce backup.

Du coup, je suis certain qu'il doit avoir une tonne de solution, mais il va falloir se tourner du coté du système.
Un système est tout de même nettement plus évolué que Php tout de même.
A mon sens, c'est là que tu pèche un peu (et moi totalement )

On peu imaginer une petite Bdd par là qui enregistrerait les manip à faire selon ce que tu proposera via cette interface Web.
Enregistrer le nom du fichier, le jour à l'exécuter, l'heure, etc, etc, que sais-je.
Le système lui, se chargerait d'analyser cette Bdd, et récupérer ce qu'il y a faire.
Ca peut se faire toutes les heures, les 1/4 heures, 1 fois/jours, 1 fois/semaine, que sais-je


Faudrait te rapprocher des administrateurs systèmes, c'est à mon sens eux qui t'apporteront des solutions en relation avec ce que tu pourras faire (en Php, Bdd, fichier, etc ...), tes connaissances quoi.
Me dis pas que tu est tout seul avec tes fichiers FT sous l'bras avec tout le boulot que ça représente, non ?


Bref. Ton problème n'est pas une histoire de temps limite d'exécution de Php en tout cas. Ca c'est un piège, faut pas tomber dedans.

[ganguill]

L'application Web doit se contenter d'uploader sur FT

L'application web permet d'exécuter des requêtes sur les tables de la base! Rien n'est uploadé directement! Cette application (en plus de permettre de faire des requêtes), permet de sélectionner sur son ordinateur le fichier à charger : c'est tout! Tout le chargement se passe avec Sql*Loader. Dans tous les cas Sql*Loader est obligatoire (ou alors par tables externes). Donc que j'appelle le fichier .bat avec mon application PHP ou avec un planificateur, c'est du pareil au même

Me dis pas que tu est tout seul avec tes fichiers FT sous l'bras avec tout le boulot que ça représente, non ?

Malheureusement si... On m'a tout simplement dit "tu télécharges les fichiers, tu les importes dans les tables selon le traitement que l'on veut faire " (si on veut étudier des informations sur tel client le 15 mai, alors on charge le fichier de données du 15 mai par exemple).

Après les gens viennent me demander des choses plus ou moins spécifiques, et j'exécute la requête correspondante (j'ai créé une sorte de petit éditeur de requêtes. A l'aide de formulaires, je sélectionne ce que je veux avoir (entre tous les champs de toutes mes tables de la base), puis PHP me créé des requêtes SQL, et l'exécute. Les résultats sont donc exportables vers Excel, ce que je donne ensuite à celui qui me l'a demandé).

Merci à vous

[RunCodePhp]

Donc que j'appelle le fichier .bat avec mon application PHP ou avec un planificateur, c'est du pareil au même

Je dirais que non justement.
Si tu lance le truc par Php, le gars est obligé d'attendre la fin de l'exécution pour ne serait ce avoir un réponse (même un bête Ok), sans compter que ça provoque un problème de timout.
En tout cas tu me l'a confirmé.

Si tu fais exécuter le truc par le système, Php pourra donner immédiatement une réponse. Déjà là, ce n'est plus pareil, car le serveur Web lui ne travail plus.
Le système, lui il bosse.
(en admettant ici ... pure exemple ... que Php aurait créer un cron, qui lui s'éxécuterait 1 minute après, et exécuterait le SQL*Loader, du fichier sélectionné)

Se pose quand même la question : Quand le système aura terminé la (grosse) moulinette ?
Et bien on peu imaginer que quelque part, dès le début de la moulinette, on place un marqueur (1), puis à la fin (0).
Ensuite un Ajax viendrait régulièrement regarder si c'est terminé ou pas.
S'il y a des opérations à faire après, et bien ils seront proposés dès que se sera terminer.

Dans tous les cas, ici l'utilisateur n'est pas bloqué, il peu utiliser son navigateur comme bon lui semble.
Enfin, si j'ai compris le problème.

Cependant, j'ai aucune connaissance système, mais peu importe, le max_execution_time() est un faux problème, c'est pas là qu'il faut agir.
Pour Php, tout au plus on peu envisager de faire patienter quelqu'un 5 minutes, mais au-delà, ça devient du délire.
Donc par défaut c'est 30 minutes, ce n'est pas un hasard que ça soit aussi peu (je dirais même que c'est déjà largement de trop).

[ganguill]

Si tu lance le truc par Php, le gars est obligé d'attendre la fin de l'exécution pour ne serait ce avoir un réponse (même un bête Ok)

L'utilisateur n'attend pas de réponse Même un simple OK ne changerait au problème, étant donné qu'il ne pourra effectuer aucune requête sur la base (en effet, la seule table pour laquelle je coince sur le timeout est la table la plus importante de ma base).
Et dans le cas de chargement multiples (si par exemple on souhaite comparer les résultats d'une même requête entre deux dates différentes), et bien la table sera effacée puis rechargée etc, et on observera comme ça les résultats pour chaque jour demandé. Dans tous les cas il faut lancer le chargement la nuit, donc message instantanné ou non...

Dans tous les cas, ici l'utilisateur n'est pas bloqué, il peu utiliser son navigateur comme bon lui semble.

Il le peut quand même Quand une table charge, le navigateur ne consomme vraiment rien en % de CPU Et même dans l'éventualité ou il fermerait par mégarde son navigateur (avec le chargement en cours), et bien la table continue de se charger quand même! Une fois Sql*Loader appelé, il continue son chargement en tâche de fond! Disons que si par contre on ferme le navigateur, on ne sait plus quand la table a fini de se remplir

Mais je tiens compte de toutes tes remarques, et je t'en remercie Quelques idées pourront toujours m'être utiles pour plus tard.

A part ça, quelqu'un saurait-il tout de même comment modifier le "Local value" du max_execution_time ??

[RunCodePhp]

set_time_limit(0);

La réponse t'avais été donnée depuis le début.
La fonction set_time_limit() agit sur la directive max_execution_time

Puis si tu modifie cette valeur (max_execution_time) du php.ini, et que tu ne constate pas de changement via un phpinfo(), et bien soit Apache n'a pas été redémarré, soit tu te trompe de php.ini

Et si tout a été pris en compte et que tu obtiens le même message d'erreur, alors ce ne serait plus une histoire de timout.
Peut être que c'est la Bdd non dispo qui provoquerait cette erreur.

Toujours est il que j'ai du mal à te comprendre, car tu dis une chose et son contraire.
Quand j'avais dis si c'était un problème de réponse, tu m'avais dis que c'était bien ça (suffit de remonter dans le topic), maintenant tu que ça ne changerait rien.

De plus, tu dis que les traitements seront à faire la nuit, ce qui supposerait qu'il y aurait plus de problème d'indisponibilité de la Bdd, mais que le SQL*Loader devrait être quand même lancé ???

C'est pas clair du tout


Juste comme ça.
Est ce que créer des vues, ou des tables temporaires ne serait pas une solution ?
Car apparemment, c'est le fait de travailler sur la même table qui cause problème, non ?

[ganguill]

Bonjour,

en fait que je parlais du problème de réponse, j'avais compris les choses comme ça :
1 - PHP lance Sql*loader (.bat)
2 - La page web est en "ouverture" tout le temps d'exécution du .bat
3 - Une fois que le .bat a fini de s'exécuter (donc qu'on a fini de charger les données avec Sql*Loader), des requêtes de nettoyage s'effectues sur ces tables (cette fois-ci entièrement exécutées par PHP).
4 - Une fois le tout terminé, la page web est enfin prête, et informe l'utilisateur que la table est prête à être utilisée.

Pour moi c'est de ça que tu parlais (enfin c'est ce que j'avais compris). Et effectivement c'est comme ça que ça se passe.
Quand je dis que ça ne changerait rien, je parle d'exécuter le .bat par PHP ou un planificateur (dans le sens ou ça ne changerait rien car je ne pourrais quand même pas utiliser la base plus vite).

J'ai donc modifié le set_time_limit(0) (c'est moi qui en a parlé dans mon premier post ), et modifié également dans le php.ini. Je constate bien les changements, mais rien n'y fait : la page me sort toujours un "the page cannot be displayed" au bout d'une heure (j'ai rechronométré, c'est vraiment 1h! ).

Tout ça pour dire qu'effectivement je vois les limites de ce que j'ai fait..
Il faut donc que je charge les tables d'une autre façon.. J'ai donc indiqué à PHP de lancer le .bat qui appelle Sql*Loader, puis quand le chargement des données est terminé, un autre .bat contenant un appel à Sql*Plus ainsi qu'à un fichier .sql contenant toutes les requêtes (les requêtes de nettoyage de "l'après-chargement" sont donc maintenant exécutées par Sql*Plus en commande DOS, et non plus par PHP).

Mais est-ce-que ça changera grand chose...

[jav806]

Alors je suis pas sur que mon grain de sel serve vraiment mais bon...

As tu vérifié si ton code ne bouclait pas à l'infinie tout seul? En lui passant quelques dizaines/centaines de reqs seulement par exemple.

Pour tes problèmes de découpe du traitement, regarde du coté d'ajax avec une suite de requêtes qui permettrait de lancer X petites requêtes plutôt qu'une énorme.

Et, là je sais totalement être hors sujet, mais quel idée d'avoir choisie php pour un truc pareil. Perso je te dirais d'arrêter les frais et de voir à une solution sur python/java/etc. Car là c'est pas du léger et php est pas vraiment le mieux adapté je dirais.

Voila pour mon grain de sel pas forcément utile

[ganguill]

Voila pour mon grain de sel pas forcément utile

Et bien si, c'est toujours utile des remarques

Alors pour le code, non ça ne boucle pas Le problème c'est qu'une fois le chargement des données effectué, les requêtes de nettoyage sont lourdes! Il y en a une dizaine environ, mais elles sont assez longues (pas à cause de PHP hein! Quand je les lances sous Sql*Plus par exemple c'est la même chose niveau temps d'exécution).

Et pour le langage disons que php était le mieux adapté (grâce aux formulaires) pour ce qui est requêtes "de résultats" (j'entend par là les vraies requêtes que l'utilisateur veut faire, celles qui donnent des résultats )!
Vu que je dois manipuler énormément de variables et d'affectation de variables de page en page, PHP était beaucoup plus pratique (et je ne te cache pas que je suis beaucoup plus à l'aise en PHP/html/css/javascript qu'en Java).

Le truc c'est que PHP n'est pas adapté pour le chargement des données dans les tables (et donc pour les requêtes de nettoyage automatique des tables aussi), mais l'est parfaitement pour les vraies requêtes! Il me faut 1 à 5 minutes pour obtenir des résultats plus ou moins précis entre plus ou moins de tables de la base)!

Enfin, j'ai trouvé une solution pour le timeout! Comme certains l'ont peut-être remarqué dans un sujet que j'ai fait, je découpe maintenant les actions! J'exécute le .bat de chargement, puis une fois terminé je recharge la page et j'exécute l'autre .bat de requêtes de nettoyage. C'est une solution qui fonctionne (pas la mieux... mais qui fonctionne)

Merci encore

[RunCodePhp]

Bon, il me semble qu'on est unanime à dire que Php ne serait pas le meilleur langage dans cette histoire, m'enfin, je comprends bien aussi le coté "plus à l'aise", donc ok, il faut faut faire avec en faite.

Le truc c'est que PHP n'est pas adapté pour le chargement des données dans les tables (et donc pour les requêtes de nettoyage automatique des tables aussi), mais l'est parfaitement pour les vraies requêtes! Il me faut 1 à 5 minutes pour obtenir des résultats plus ou moins précis entre plus ou moins de tables de la base)!

Et bien, peut être qu'ici il y aurait moyen de "gratter" du temps, car en faite, le truc serait : Moins Php en fait, mieux ça sera.
MySQL intègre tout de même pas mal de choses depuis la version 5, comme créer ses propres fonctions, procédure stockée, et intègre aussi pas mal de fonctions.
Peut être faudrait il te pencher la dessus pour voir s'il y a pas moyen de faire ces tâches de nettoyage uniquement ou en parti avec MySQL.
Aussi, j'avais évoqué que MySQL offre des solutions comme des tables temporaires, ou des vues.