php : définir une '"zone critique" du script ?

php : définir une '"zone critique" du script ? - PHP - Programmation

Marsh Posté le 09-12-2005 à 10:19:30    

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.

Reply

Marsh Posté le 09-12-2005 à 10:19:30   

Reply

Marsh Posté le 09-12-2005 à 10:48:16    

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?


---------------
MZP est de retour
Reply

Marsh Posté le 09-12-2005 à 12:01:08    

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

Reply

Marsh Posté le 09-12-2005 à 12:24:33    

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


---------------
MZP est de retour
Reply

Marsh Posté le 09-12-2005 à 12:45:35    

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.


Message édité par Profil supprimé le 09-12-2005 à 12:46:09
Reply

Marsh Posté le 09-12-2005 à 13:43:07    

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


---------------
MZP est de retour
Reply

Marsh Posté le 09-12-2005 à 13:56:05    

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 :D
 
en moins de 5 secondes tu analyse combien de clics, ou sessions ?

Reply

Marsh Posté le 09-12-2005 à 14:22:57    

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.


Message édité par cinocks le 09-12-2005 à 14:23:47

---------------
MZP est de retour
Reply

Marsh Posté le 09-12-2005 à 14:24:03    

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


---------------
MZP est de retour
Reply

Marsh Posté le 09-12-2005 à 14:26:45    

après checking, c'est mes requêtes qui prennent du temps (forcement, des tables avec  jusqu'a 300.000 enregistrements :D)
 
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)

Reply

Marsh Posté le 09-12-2005 à 14:26:45   

Reply

Marsh Posté le 09-12-2005 à 14:37:25    

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.


---------------
MZP est de retour
Reply

Marsh Posté le 09-12-2005 à 14:39:59    

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 :D

Reply

Marsh Posté le 09-12-2005 à 14:54:08    

En gros, on reinvente tous la roue. :lol:


---------------
MZP est de retour
Reply

Marsh Posté le 09-12-2005 à 15:00:32    

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 !

Reply

Marsh Posté le 09-12-2005 à 15:00:51    

je ne sais faire que ca :lol:


---------------
MZP est de retour
Reply

Marsh Posté le 09-12-2005 à 15:19:57    

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  
 

Code :
  1. select x from table
  2.    foreach x
  3.       select y from table2 where titi=x

Reply

Marsh Posté le 09-12-2005 à 15:24:59    

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.  
 
 [:ciler]  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.

Reply

Marsh Posté le 09-12-2005 à 15:30:10    

=> 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)


Message édité par Profil supprimé le 09-12-2005 à 15:40:26
Reply

Marsh Posté le 09-12-2005 à 15:41:23    

Berceker United a écrit :

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.  
 
 [:ciler]  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.


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

Reply

Marsh Posté le 09-12-2005 à 16:56:06    


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.

Reply

Marsh Posté le 09-12-2005 à 17:18:53    

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.

Reply

Marsh Posté le 09-12-2005 à 17:19:51    

"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 :cry:

Reply

Marsh Posté le 09-12-2005 à 17:22:21    

si mais tu stockes en tableau le resultat.


---------------
MZP est de retour
Reply

Marsh Posté le 09-12-2005 à 18:39:21    


Je t'avais prevenu! [:chewyy] pas de croisement de requete avec cette fonction

Reply

Marsh Posté le 09-12-2005 à 20:10:22    

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

Reply

Marsh Posté le 10-12-2005 à 02:54:30    

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 :D
Au lieu de passer quelques secondes au premier coup où t'as tout :)

Reply

Marsh Posté le 10-12-2005 à 09:09:30    

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

Message cité 1 fois
Message édité par black_lord le 10-12-2005 à 09:10:18

---------------
uptime is for lousy system administrators what Viagra is for impotent people - mes unixeries - github me
Reply

Marsh Posté le 10-12-2005 à 09:14:36    

black_lord a écrit :

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


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.

Reply

Marsh Posté le 10-12-2005 à 09:16:01    

Berceker United a écrit :

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 :o sinon il peut arrêter le topic de suite :D


---------------
uptime is for lousy system administrators what Viagra is for impotent people - mes unixeries - github me
Reply

Marsh Posté le 10-12-2005 à 09:20:50    

black_lord a écrit :

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


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

Reply

Marsh Posté le 10-12-2005 à 10:39:05    

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


---------------
Nos estans firs di nosse pitite patreye...
Reply

Marsh Posté le 10-12-2005 à 10:41:54    

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


---------------
uptime is for lousy system administrators what Viagra is for impotent people - mes unixeries - github me
Reply

Marsh Posté le 10-12-2005 à 10:45:25    

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


---------------
Nos estans firs di nosse pitite patreye...
Reply

Marsh Posté le 10-12-2005 à 20:18:42    

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

Reply

Marsh Posté le 10-12-2005 à 20:23:42    

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


---------------
Nos estans firs di nosse pitite patreye...
Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed