petit-ourson Posté 18 Mai 2006 Partager Posté 18 Mai 2006 Bonsoir, Voilà je me heurte à un soucis. J'ai besoin de quelques conseils. J'ai un gros traitement à éxécuter sur une table de 120 000 lignes. Je fais ma requête et je stocke le résultat de celle-ci dans un tableau qui fera donc le nombre de lignes que le résultat de ma requête (ça me permet de libérer ma connexion SQL). Ensuite j'ai un traitement à faire pour chacune de ses lignes de mon tableau. Il faut que je gère si une coupure involontaire (panne de courant, script qui déconne, innondation et tout ce que vous voullez) intervient afin de pouvoir reprendre au point où j'etais arrivé. Donc la solution que j'ai trouvé c'est d'indiquer dans ma base à chaque ligne traitée que cela a été fait. J'ai peur que 120 000 update fait en peu de temps ne soit pas la meilleure des solutions. Dois-je temporisé mon script, il y a un moyen de donné une priorité réduite à un script ? Il faudrait pas que cela dégrade toutes les perfs de mon serveur pour autant. En fait ce sera toujours la même requête incrémenté de 1 (correspondant à la dernière ligne traitée). -- Merci d'avance Lien vers le commentaire Partager sur d’autres sites More sharing options...
Dan Posté 18 Mai 2006 Partager Posté 18 Mai 2006 Bonsoir, Je suis tombé sur un post sur WRI où j'y ai appris que le membre utilisait cette boucle pour envoyer un email à 120 000 personnes. Je ne sais pas si c'est toi ? http://www.webrankinfo.com/forums/viewtopic_52167.htm Dans l'affirmative, je te suggèrerais comme ils l'ont fait: utilise un logiciel de gestion de newsletter pour cela. Appeler 120000 fois la commande mail() revient à ouvrir un nouveau socket pour chaque invocation... pas terrible comme procédé De plus ce type de logiciel te permettra de gérer les bounces inévitables... Dan Lien vers le commentaire Partager sur d’autres sites More sharing options...
petit-ourson Posté 18 Mai 2006 Auteur Partager Posté 18 Mai 2006 (modifié) Non ce n'est pas moi mais je rebondi sur ce message pour me cultiver ;o) Tu appelles quoi par "bounce ?" Modifié 18 Mai 2006 par petit-ourson Lien vers le commentaire Partager sur d’autres sites More sharing options...
webadev Posté 18 Mai 2006 Partager Posté 18 Mai 2006 Un mail a 120 000 personnes cela sent quand meme le spam. Hervé Lien vers le commentaire Partager sur d’autres sites More sharing options...
Dan Posté 18 Mai 2006 Partager Posté 18 Mai 2006 Un bounce est un email qui revient suite à une mauvaise adresse email du destinataire. Lien vers le commentaire Partager sur d’autres sites More sharing options...
petit-ourson Posté 18 Mai 2006 Auteur Partager Posté 18 Mai 2006 Un mail a 120 000 personnes cela sent quand meme le spam. Hervé <{POST_SNAPBACK}> Ouaip à moins que ce soit un email personnalisé à toute une base cliente. Qui n'a pas pas déjà envoyé un mail à une base de 3 millions de personnes ? Lien vers le commentaire Partager sur d’autres sites More sharing options...
captain_torche Posté 18 Mai 2006 Partager Posté 18 Mai 2006 Sinon, pour ton problème, plutôt que de te reconnecter à ta bdd ,tu ne pourrais pas juste écrire l'id de l'enregistrement traité dans un fichier ? Lien vers le commentaire Partager sur d’autres sites More sharing options...
petit-ourson Posté 18 Mai 2006 Auteur Partager Posté 18 Mai 2006 Sinon, pour ton problème, plutôt que de te reconnecter à ta bdd ,tu ne pourrais pas juste écrire l'id de l'enregistrement traité dans un fichier ? <{POST_SNAPBACK}> Oui je sais pas ce qui est le plus rapide en fait, faudrait que je fasse quelques tests. Lien vers le commentaire Partager sur d’autres sites More sharing options...
Anonymus Posté 18 Mai 2006 Partager Posté 18 Mai 2006 Tu peux t'aider de la commande 'sleep', pour que ton programme temporise un peu : sleep(10); arretera le programme 10 secondes. Tu peux aussi jeter un oeil à l'inévitable 'set_time_limit(86400); qui va te faire durer le script pendant une journée (86400 secondes). Mais de manière générale, ton script de 120 000 lignes va s'executer très rapidement... Le temps de te demander si les mails sont partis qu'ils le sont déjà.. tous Mais il est vrai que le 'plantage' au milieu de la table est... génant.. Au lieu d'un 'update', pourquoi ne pas noter les mails que tu as envoyé dans un fichier texte ? A la fin, tu vérifies si la dernière ligne de ton fichier est bien la dernière ligne de ta base, et le tour est joué Enfin, n'oublies pas (si ce sont des mails..) de mettre ton adresse à 2-3 endroits de la base, histoire de voir si tu recois bien, toi aussi, ces mails Tant qu'à faire, mets y plusieurs adresses mails distinctes Anonymus. Lien vers le commentaire Partager sur d’autres sites More sharing options...
xou Posté 19 Mai 2006 Partager Posté 19 Mai 2006 Deux conseils: 1. je confirme, autant utiliser un fichier texte pour ton contrôle: celà t'évitera de charger d'avantage ta db. 2. utilises une connection smtp et non la fonction mail() de php, c'est tout à fait faisable en php. Tu aura moins de problème pour la création de ton script et encore moins pour son exploitation. Lien vers le commentaire Partager sur d’autres sites More sharing options...
petit-ourson Posté 19 Mai 2006 Auteur Partager Posté 19 Mai 2006 Oui enfin dans mon cas ce n'était pas des mails que j'ai à envoyer (je crois que finalement deux posts ont été téléscopé) Sinon oui une connection au serveur par socket est à utiliser plutôt que la fonction mail(). Lien vers le commentaire Partager sur d’autres sites More sharing options...
destroyedlolo Posté 20 Mai 2006 Partager Posté 20 Mai 2006 J'ai ce genre de gros scripts qui prennent plusieurs heures a s'executer (generation de statistique). La solution que j'ai utiliser a ete de les lancer par la commande unix batch en configurant mes queues pour les lancer en nice. L'interet du batch, est que les scripts en question ne seront lancer que si la charge systeme le permet ... ce qui permet aussi d'eviter que 2 soient lances en meme temps. Bref, ils tournent quant ils peuvent en tache de fond sur mon systeme et l'impacte est plus que negligeable pour les visiteurs interactifs. Lien vers le commentaire Partager sur d’autres sites More sharing options...
Sujets conseillés
Veuillez vous connecter pour commenter
Vous pourrez laisser un commentaire après vous êtes connecté.
Connectez-vous maintenant