Bonjour.
 
J'ai un script PHP qui fait des analyses très lourdingues sur des bases de données brutes (pour du tracking) et qui prend des heures pour s'executer.
 
Il s'arrete automatiquement au bout du time_limit, et si je met le time_limit a zero il s'arrete quand même au bout de qq heures, alors que les traitements ne sont pas terminés.
 
J'ai bien peur que le programme se stoppe un peu n'importe où dans le script. Il y a une zone de qq dizaines de lignes où le programme ne devrai absolument pas s'arreter.
 
Comment spécifier ca ? expliciter une zone où le programme ne doit absolument pas s'arreter, ou alors expliciter une zone ou le programme a "le droit" de s'arreter si le time out est atteind.
 
En esperant avoir été clair..
 
Merci d'avance.

Tu n'es pas maitre sur l'arret d'un script. A moins de le lancer en mode console.
Tu n'aurais pas plutot moyen de reduire le temps de traitements. Plusieurs heures, ca fait tout de même beaucoup.
 
tu as quelle volumetrie à traiter à chaque fois?

une bonne cinquantaine de megas
 
je peut le lancer en mode console !!! comment maitriser l'arret du script en mode console ?
 
a part "man php"

aucune idée. Je n'en ai pas encore eu besoin. Je sais que l'on peut le faire.  
 
50 megas ce n'est pas beaucoup. Ce sont des logs, données en base.

ce sont des données brutes (en base) issues d'un tracking, qui sont relativement lourdes a analyser et le seront de plus en plus avec l'augmentation du tarffic sur le site.
 
je pense lancer le script  en console, j'ai regardé dans le man mais j'ai pas trouvé comment controller l'arret du script.

J'aimerai bien connaitre ce que tu analyses. J'en fais aussi, mais ca ce calcule en moins de 5 secondes pour moi.

c un site de vpc, avec des entrées en bdd pour a peu près chaque clic, produit ajouté au panier, etc etc etc et a partir de ca je sors des données "organnisées" pour être exploitable.
je suis en train de developer le truc et j'ai les données brutes de plusieurs jours à analyser donc c lourdeau.
 
je crois que mon algo est pas du tout optimisé enfin je suis en train de bosser dessus je devrai arriver a me demerder pour le rendre bcp plus rapide
 
en moins de 5 secondes tu analyse combien de clics, ou sessions ?

Peu de clic pour le moment. Ca tourne à 3300 appels par jour. Mes stats actuelles ne necessite pas l'intervention de PHP. Je fais x regroupement d'informations. C'est dejà beaucoup moins consommateur.
 
J'ai actuellement plusieurs traitements de stats qui tournent tout au long de la journée. Chacun tourne toutes les 15 minutes. Ca mets moins d'une seconde par script.

Bien sur, j'imagine que l'on a pas du tout le meme volume

après checking, c'est mes requêtes qui prennent du temps (forcement, des tables avec  jusqu'a 300.000 enregistrements )
 
donc une fois mon retard rattrappé en mettant le script dans un cron très régulier ca devrai prendre bcp moins de temps (comme les tables seront "nettoyées" au fur et a mesure)

C'est exactement ce que je fais. Je regroupe mes stats par bloc horaire avec un minimum de 5 minutes. Par contre, je n'ai pas le meme volume. Au debut de mes stats, je loggais tout en attendant de le traiter. Ca a mis 2 minutes pour tout traiter lorsque j'ai mis en place les traitements.

yep j'ai bien l'intention de faire ca ct prévu dès le début mais comme je devai absolument sortir les stats de la période dès que j'ai commencé a dev le truc j'ai du stocker au début

En gros, on reinvente tous la roue.

je crois qu'il existe des trucs free pour du tracking mais bon le temps de les adapter a ton problème particulier, ca va plus vite de reinventer la roue !

je ne sais faire que ca

Essaye de récupérer le temps de traitement par php et le temps d'accès à la bd mais c'est sur que ça doit plutot être un truc pas optimisé côté bd (index, requête...) et peut être que tu pourrais faire en 1 requête un truc sur lequel tu bloucles avec d'autres requêtes C'est horriblement consommateur ça Genre  
 

remplace la fonction mysql_query par mysql_unbuffered_query s'il y a pas de requete croisé sa pourrait fonctionner et donc aller plus vite.  
 
   Quelques heures ho puneze j'en suis sur qu'il y a moyen de réduire le temps de traitement. Cette solution n'est pas jouable pour moi.

=> leflos5
 
oui y'a un peu de ca aussi mais c difficilement évitable avec la structure de mes fonctions (quique je vais essayer d'optimiser un max).
 
ceci dit j'ai testé les requetes et elles prennent faiclement une seconde (tables très très grosses) donc c bien mes requetes qui retardent le prog (au fur et a mesure de la purge des tables ca devrai s'améliorer)

j'ai essayé de toutes les remplacer bourinement et ca a planté LOL
 
moi et la finesse...
 
vais essayer de peaufiner mais j'ai pas trop compri les subtilités de unbeffered query

Comme son nom l'indique , le unbuffered_query ne place pas le jeux de resultat en mémoire , il le balance directement. Donc il y a un gain de temps et de mémoire à l'instant T.  
Regarde la doc sur cette fonction.

bah j'ai regardé ca m'a semblé clair, mais en testant ca plante quand une requete utilise le résultat d'une requete différente.
 
doit y avoir une combine ou une subtilité que j'ai pas saisi.

"Vous devez aussi lire tous les résultats d'une première requête exécutée avec mysql_unbuffered_query(), avant de pouvoir en exécuter une autre."
 
Boum.
j'ai pas le droit de l'utiliser

si mais tu stockes en tableau le resultat.

Je t'avais prevenu! pas de croisement de requete avec cette fonction

l'utilisation est donc très limitée.
 
si on utilise les results de suite après l'appel de la fonction ca risque pas de poser de pb? (genre si le mysql est trop lent) ?
 
vais qd même essayer de l'utiliser pr optimiser un poil

Bah refonds tes fonctions et chie une requête qui a tout ce qu'il faut dès le départ
Parce que 1s par requête si ça boucle et que t'as 3600 enregistrement à traiter un par un après, ça fait une heure
Au lieu de passer quelques secondes au premier coup où t'as tout

A mon avis pour ce volume de traitements tu devrais envisager autre chose que PHP
 
Genre tu recodes ça en perl que tu fous dans un cron, parce que là c'est un non sens ce que tu fais
 
EDIT : et optimises tes requêtes, c'est un bon point de départ

Tu auras beau optimiser les requêtes si déjà les tables et les données sont mal agencé il faut voir les données des tables avant toute chose.

j'ai supposé que l'analyse était correcte hein sinon il peut arrêter le topic de suite

Ben tu sais tu peux voir de sacré surprise et comprendre pourquoi l'opération dure si longtemps. Moi je penche plus pour ça

pour répondre a la question de départ, je dirait qu'un seul mot : transaction

a priori il fait surtout de la lecture donc là les transactions c'est un peu

si il fait pas d'ecriture je vois pas en quoi il a des zones "critiques"

y'a de la lecture et de l'écriture.
 
c'est quoi els trasactions ?

dis t'as cherché dans les pages d'or sur google ?