How to send 12 000 emails via Swiftmailer in Symfony2?

Question

Sometimes we need to send many emails. We are selecting users by 100, for each user create mail, send it (add to spool), make $em->clear(). But even in production env we cann't send much than 4000 emails: got "Unable allocate memory".

What proper way to do that? Add argument to our command end execute it many times using --skip=4000?

Answer 1

What we do, is we thread it... so, let's say you have a table with your users and you've got an ID and EMAIL column. We assume that there will be more/less an equal number of ID's ending on zero, than there is ending on 1, 2, etc.

Now we have our script that sends emails only send emails to the people who end on say zero, and another script that sends to people who's id fields end with 1, etc. Example, you use parameters to define this, let's say your script is called "send-a-lot.php", you'll run these 10 commands:

php send-a-lot.php --ending-on=0
php send-a-lot.php --ending-on=1
php send-a-lot.php --ending-on=2
php send-a-lot.php --ending-on=3
php send-a-lot.php --ending-on=4
php send-a-lot.php --ending-on=5
php send-a-lot.php --ending-on=6
php send-a-lot.php --ending-on=7
php send-a-lot.php --ending-on=8
php send-a-lot.php --ending-on=9

Inside your code, you want to do something like:

if ($id % 10 == $endingOnParameter) {
  // send the mail
}

It's not exactly what you were asking, but at least that's what we did to help "some" of our load problem

Answer 2

I mention my experience: I send about 8000 personal emails with symfony and SwiftMailer on a shared server with very limited resources. I had a table with users and create a task or command in which to make a paginated query, and passing the page size via parameter in my task. Y executed this task or command on a cron job every 30 minutes. You can configure depending of your resourses. With query page size you manage how many emails will be send, and with cron job you can manage the time between lots. I acknowledge that there are more professional and robust solutions, but this was the only way I found on a shared server with limited resources.