Discussion :

[randriano]

Bonjour,

Je développe une application web qui nécessite un traitement long, à priori plus de 25 mn.
Le soucis c'est que lorsqu'on lance le script PHP que ce soit un appel sur un navigateur (utilisation d'Apache+PHP) ou par ligne de commande (uniquement PHP), le script s'arrête au bout de 5 minutes exactement ( = 300 s) sans message d'erreur!

Tous les paramètres possibles de réglage ont été modifiés: timeout, mémoire!
Dans tous les php.ini:

Code :

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

1
2
max_execution_time = 3000
memory_limit = 512M

Ainsi que dans httpd.conf, ce qui n'est pas nécessaire pour l'exécution en ligne de commande.

Code :

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

1
2
3
4
Timeout 3000
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 15

Est-ce que ce 300secondes est "hardcoded" dans les exécutables PHP?

Y a-t-il une technique pour contourner une telle limite de durée d'exécution?

Merci d'avance.

[randriano]

Je ne comprends toujours pas les 5 minutes persistent mais j'ai trouvé une solution de contournement:
c'est faire appel à la fonction set_time_limit() de PHP à chaque itération de mon programme qui nécessite beaucoup de temps!

J'utilise même set_time_limit(0) qui veut dire qu'aucune limite n'est imposée!

Code :

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

1
2
3
4
5
6
7
8
9
10
11
$qryResult = $CIInstance->db->query(
	"SELECT 
		*
	FROM 
		entreprises
	");
 
foreach($qryResult->result() as $entreprise) {
......................	
	set_time_limit(0);         
}

Maintenant, mon script ne s'interrompt plus, il est même sollicité pour plus de 40 minutes dans certains cas.

[rawsrc]

Salut,

Bon la durée limite d'exécution d'un script n'est pas "hardcoded" dans le PHP.
Par contre, un script qui met 25 ou 40 minutes pour effectuer un traitement me parait absurde.
Tu es sûr de ton coup ? Tu ne peux pas déporter ces traitement dans la base de données par exemple avec une procédure ou fonction stockée ?
Dans tous les cas, dis-toi bien que ton approche est loin d'être la panacée.

Allez poste voir ton script (celui qui pète un record)

[randriano]

Oui je suis sûr de mon coup Il s'agit de l'analyse et de la ventilation d'un fichier Excel de 50000 lignes avec 104 colonnes vers une base de données MySql. On ne peut donc pas le déporter vers une procédure stockée.

Je t'assure que cette durée est normale! Il ne s'agit pas d'un site web mais d'une application web.

[rawsrc]

Salut

ah ça tombe bien, je me suis cogné l'analyse, la ventilation et l'import des données d'un fichier excel de 54 colonnes sur plus de 30 000 lignes. En PHP de le traitement prenait de 25 à 30 minutes, une fois le module codé en procédures stockées : 3 minutes 30. Donc tu as encore de l'espoir.

[randriano]

En PHP de le traitement prenait de 25 à 30 minutes, une fois le module codé en procédures stockées : 3 minutes 30. Donc tu as encore de l'espoir.

Explique s'il te plaît! C'est de l'importation du fichier Excel vers la base de données dont tu parles?

Pour l'instant, on fait l'analyse de la table une fois remplie encore côté PHP car c'est pratique pour nos tests "unitaires".

[rawsrc]

Alors voici comment j'ai fait :
dans un premier temps j'ai développé un grosse routine d'analyse et de validation des données dans le fichier Excel en VBA. Cela permet de nettoyer toutes les erreurs de cohérence et diverses anomalies de formatage (tout ça de moins à coder en SQL).

Une fois que cette routine ne génère plus aucune erreur et que tous les problèmes ont été corrigés, on passe à l'importation de la feuille excel brute dans une table de la base de donnée à l'image exacte du tableau excel.
Pour cette étape, soit tu passes par du csv soit tu utilises un outil d'import de données (pour 50 colonnes, il vaut mieux un outil car tu peux conserver le mapping excel -> db pour une prochaine ré-utilisation)

Préparation des tables de logs et lancement de la procédure stockée principale pilotant tout le processus d'importation.

Le truc c'est que tu dois recoder ton module en procédures/fonctions stockées. Cela nécessite quand même une bonne connaissance du SQL.
Et au final, ne reste plus qu'à consulter le log d'import et vérifier tout ce qui a posé problème ou a été rejeté.

Le module d'importation s'étale sur 32 procédures et 24 fonctions stockées. L'avantage c'est que ça dépote et ne te plante pas le serveur PHP pour 40 minutes.

[randriano]

.........en VBA.............
U.............tu passes par du csv soit tu utilises un outil d'import de données.......
............................

S'il faut faire tout ça donc cela ne correspond pas du tout à nos attentes, nous on n'y touche pas aux Excel car un utilisateur ne saurait pas faire tout ce tralala, il a juste à charger le fichier Excel depuis un <input type='file' et hop mon code PHP fait tout, car il n'y a pas qu'un fichier Excel mais plusieurs.

[rawsrc]

Salut,

tout ce "tralala" comme tu dis n'est clairement pas à faire au quotidien. Dans mon cas de figure, les importations de données sont généralement faites sporadiquement lors d'une migration partielle. Et ce n'est pas aux utilisateurs lambdas de les faire.

Si tes utilisateurs doivent le faire plus ou moins quotidiennement sur des fichiers de plus de 100 colonnes avec 50 000 lignes c'est qu'il y a peut-être un problème dans le process de travail. Si pour pouvoir travailler et rester fiable, il faut se coltiner des imports aussi massifs, il faudrait voir si il ne serait pas possible d'aller attaquer directement les données à la source. J'entends par là, la source qui a servi à générer les fichiers excel.

Bref, je pense qu'il faut s'interroger sur la manière de faire et peut-être aussi se poser la question de la responsabilité de cette tâche.

[randriano]

En fait, notre job consiste juste à créer un programme (en PHP) pour traiter les fichiers Excel sans rien demander d'autres à ceux qui livrent les fichiers Excel.

Donc on n'a pas à poser des questions sur la source de ces fichiers, puisque l'application sera utilisée par des tiers, aucun autre traitement ne sera à faire sur les fichiers du genre les transformer en fichier csv ou ...

En tout cas, pour mon souci de timeout, la solution que j'ai évoquée au message n°2 nous aide beaucoup mais n'a pas répondu à ma question sur pourquoi la configuration de max_execution_time à 0 ou à 100000 ne l'a pas résolu.

[rawsrc]

Salut,

Tu dois absolument sortir set_time_limit() de ta boucle.
A chaque fois que tu redéfinis le temps maximum d'exécution, le Zend Engine s'embarque dans une routine qui consomme un max de temps ici.
En plus c'est une directive globale de configuration, donc une fois définie elle s'appliquera à l'ensemble du traitement.

Après pour max_execution_time, il faut lire la doc sur les raisons du pourquoi du comment ici

[randriano]

Merci rawsrc pour ces liens!

Je vais citer donc ce que dit le manuel php:

max_execution_time (entier)

Fixe le temps maximal d'exécution d'un script, en secondes. Cela permet d'éviter que des scripts en boucles infinies saturent le serveur. La configuration par défaut est de 30 secondes. Lorsque PHP fonctionne depuis la ligne de commande, la valeur par défaut est 0.

Le temps d'exécution maximum n'est pas affecté par des appels systèmes tels que sleep(). Reportez-vous à la fonction set_time_limit() pour plus de détails.

Vous ne pouvez pas modifier la valeur de cette directive avec ini_set() lorsque PHP est configuré en safe mode. Le seul moyen de le faire est de désactiver le safe mode ou de changer la valeur dans php.ini.

Votre serveur web peut avoir d'autres configurations de la durée limite d'exécution qui peuvent également interrompre PHP. Apache a une directive Timeout et IIS a une fonction CGI pour cela. Par défaut, elles valent toutes les deux 300 secondes. Reportez-vous à la documentation de votre serveur web pour plus de détails.

Je vais également sortir le set_time_limit(0) de la boucle!