Discussion :

[mookmook]

Bonjour, j'ai une question qui relève plus d'architecture que de développement à proprement parler.

J'ai un projet qui connait une forte croissance en terme de volumes de données et de nombre d'utilisateurs.
Typiquement nous utilisons des crons pour effectuer des tâches répétitives, mais ça commence à être chaud (time limit, problèmes de mémoire)

Par exemple : J'ai 1 million d'utilisateurs, comment je fais pour leur envoyer tous les jours des notifications ?
genre j'ai un foreach() avec 20 000 objets clients, et pour chaque client je crée une instance message, que j'envoie, etc ... => mais c'est très lourd, trop lourd, les scripts plantent.

Précision: les emails sont déjà mis dans un spool

Est-ce que ce genre de problème se résoud par de l'archi au niveau php ? Mais la je vois pas comment, même en refactorisant mes scripts dans tous les sens, j'ai toujours des volumes énormes de données à traiter.

Est-ce qu'il faut juste rajouter des serveurs pour que les crons puissent tourner sans broncher?

Est-ce que j'ai loupé un truc, et que c'est pas les crons qu'il faut utiliser pour ce genre de cas ? quels outils ?

Ma problématique tourne principalement autour du mailing.


Merci d'avance pour vos éclairages.

[sabotage]

Déjà il est anormal que ton script plante.
Il peut dépasser le temps autorisé mais visiblement tu ne fais pas des traitement dramatiques donc il n'y a pas de raison que cela se passe mal, même sur un nombre important de traitement.
Cependant c'est difficile d'analyser ta situation sans savoir précisément ce que tu fais et les erreurs que tu as.

Sur le fond du problème, tu n'es pas obligé d'avoir un script qui traite les 20000 utilisateurs.
Il suffit que ton script traite disons 100 utilisateurs et pour ces 100 utilisateurs tu stockes l'informations qu'ils ont été traités.
Ton script est relancé périodiquement et va donc traiter 100 autres utilisateurs.
etc.

[mookmook]

merci,

Difficile pour moi de décrire les problèmes car je me pose plus une question de fond, et il faudrait que je te poste mon modèle complet (pas mal de code + MCD), bon courage pour tout comprendre

Bon déjà ça me rassure de savoir que les cronjobs sont utilisables pour traiter un gros volume de données,
Au départ on faisait certains traitements en live mais on s'est vite rendu compte que l'utilisateur allait attendre sa page un bon moment ...

Mais imaginons le cas suivant : Je dois parcourir la liste de mes clients pour savoir si je dois ou pas leur envoyer une notification, cette notification est personnalisée donc je dois fetcher chaque ligne de ma table client.

Si je met un flag comme tu le conseille, et que je traite xxx clients à la fois, toutes les 5 minutes, ma file d'attente va s'allonger, et mon client recevra sa notification beaucoup trop de temps après.

J'ai vu des choses genre gearman, beanstalkd ? ça t'inspire quelquechose ?

[mookmook]

Je commence à résoudre mes problèmes, voici mes conclusions :

- ma base de données est visiblement mal conçue (je reprend du code existant )
- pour traiter de gros volumes de données, je vais passer par des flags, donc je traite 1000 clients toutes les minutes, et je stocke le fait que je les ai traités
- pour ne pas avoir plusieurs crons qui se montent dessus et qui essaient d'écrire tous sur la table client, je vais stoker les ids des clients que j'ai traité dans une table séparée par cron


Merci

[Aurélien LEQUOY]

la solution a ton problème de mémoire ne un seul mot : Yield
remplace le cron par un daemon

[bretus]

Bonjour,

Est-ce que ce genre de problème se résoud par de l'archi au niveau php ? Mais la je vois pas comment, même en refactorisant mes scripts dans tous les sens, j'ai toujours des volumes énormes de données à traiter.

Je pense qu'un élément qui peut t'aider en terme d'architecture est le concept de pile de message (message queue) qui tend à se répandre via l'utilisation de RabbitMQ.

En bref, quand tu as un traitement asynchrone à effectuer, au lieu de marquer l'utilisateur comme "à traiter", tu ajoutes un message dans la pile avec les informations nécessaires pour effectuer le traitement (l'action à effectuer = le nom du message, l'identifiant de l'utilisateur). Via un cron, tu traites ces messages, ce qui t'éviteras de scanner toutes la table utilisateurs pour connaître les traitements à effectuer.

Après, pour les traitements périodiques du type "toutes les heures, on met à jour des statistiques", tu peux ajouter un périodiquement un message à la pile via un cron (toutes les 60 minutes, ajouter le message "calcul_statistique").