Discussion :

[boubil]

Bonjour

Pour un projet que je développe avec ZendFramework, j'ai un petit problème.
Parmi les fonctionnalités que je dois implémenter il y a la génération d'un fichier d'export d'une table particulièrement grosse (> 20 000 enregistrements).
Si mon script traite toute la table je vais surement être confrontée au dépassement du délais d'exécution.


Voici les idées que j'ai pour résoudre ce problème. Peut être en existe-til de meilleure solution.



Traiter par ex 1000 lignes, enregistrer dans un fichier temporaire le résultat et dans un autre fichier l'ID max atteint, et rediriger vers la même action, qui récupère l'ID max soit en parametre soit dans le fichier et traite les 1000 lignes suivante et ainsi de suite jusqu'a l'épuisement des données à exporter. A la fin l'action met le fichier généré à disposition du client.
En cas de pb le systeme est capable de faire une reprise sur erreur en repartant du dernier ID enregistré dans le fichier.

Ainsi, je suppose qu'a chaque itération il s'agira d'un nouvel appel donc je ne devrais pas avoir ce pb de max execution time.

Est ce que je risque d'avoir un pb avec le navigateur qui détecte des redirections en boucle ?

Est ce qu'il y a un meilleur moyen de traiter ce type de problèmes ?

Est ce qu'il y a un moyen pour qu'a chaque itération je puisse afficher la progression au client ?

Merci d'avance

Nathalie

[gmarsay]

Tu peux soit faire les traitements par lots, comme tu l'as indiqué, ou alors modifier la valeur de déclenchement du timeout : http://php.net/manual/fr/function.set-time-limit.php

Pour suivre la progression tu peux faire ça en ajax.
Une première requête ajax appel ton script qui fait les traitements, et qui par la même occasion met à jour un champs dans la base de données ou un fichier pour stocker l'état d'avancement. Et une deuxième requête ajax (exécutées toutes les secondes par exemple) qui récupère l'état d'avancement et l'affiche au client.

[boubil]

Merci pour ta réponse.

par contre si l'appel du script d'export se fait en ajax, je peux lui faire faire une redirection ? Ca va marcher ?
Ca serait idéal du point de vue du client ca serait plus propre.

[5h4rk]

Bonjour,
L'appel ajax n'a pas de limite d'exécution il me semble, d'ailleurs heureusement.

Pour changer le temps d'exécution, il suffit que tu le mettes sur le fichier interrogé.

[ascito]

si c'est une tache habituelle, plutôt que faire cela à la main, une tache chron, avec le fichier de traitement dans cgi-bin?

[boubil]

L'appel ajax a forcement un temps limite d'execution s'il execute du code php : celui du serveur php !
Et je ne crois pas que je puisse faire le coup de la redirection a un appel ajax (l'ajax appel un controller/action qui se rappelle lui même x fois avant de renvoyer un retour a l'ajax).

Par ailleurs, je pense que changer le max execution time n'est pas une solution, il y a toujours un jour ou ca durera trop longtemps (j'en ai bavé avec phpMyAdmin pour importer les données dans ma base) , et de toutes façon, mon programme sera sur un serveur hébergé donc je vais devoir me contenter des 30 secondes !

J'ai implémenté en faisait une redirection et en passant l'ID dans l'URL. Les temps d'exécution sont assez bon (moins de 30 sec pour exporter 15 000 lignes par paquets de 1000 - mon PC est un bouzin, il arrive tout juste a faire tourner eclipse). Du coup pas besoin de m’embêter à stocker l'ID temporairement. En vas d'échec on recommence à zéro !

[5h4rk]

Non l'appel ajax n'a pas la limite du serveur car il s'agit de javascript donc côté client et non serveur.

Il faudrait peut être plus que tu nous expliques clairement ton problème, peut être avons nous la solution.

Peut être une optimisation ou une autre façon de faire