views:

281

answers:

3

I know about persisting the email into the db and then letting some periodical job handle the actual sending. I know that ar_mailer gem does this.

Are there any other approaches? Are there better alternatives? Simply, What is the best way to handle sending many emails in Rails?

+2  A: 

ar_mailer is the best way that I know of to send multiple emails. It's pretty intuitive to set up. I'd check out the official documentation and this really good blog post.

Dary

Dary
A: 

We are off-loading long tasks, not only email sending but also some other things using Workling and Starling (see the Railscast on how to use). There are alternatives too, Github is using delayed_job.

Mihai A
+1  A: 

In addition to the other answers I just wanted to add:

ar_mailer could work for sending a "lot" of emails, but if you are sending a LOT lot of emails (I'm thinking something like Aweber here, or CampaignMonitor, where there could be hundreds of thousands per hour) I'm not sure if ar_mailer is ideal. The reason being that it adds a separate record to the database for EACH email. Imagine you are Aweber and have a client send an email to his list of 10,000 people. You just had to create 10,000 active record objects and save all 10,000 of them to the database. This is expensive with validations and callbacks, etc. Now imagine you have 100 clients with lists of 10,000 people all sending emails that hour. Your DB will be in pain I think, unless you can eliminate the validations/callbacks etc and get into lower level DB calls.

Another option would be to just pass all the queueing off to Postfix or something like that. If Postfix somehow died in the middle of the queue, you probably wouldn't have any way to determine this from inside your rails app tho, so it's somewhat decoupled at that point, but probably way more efficient. I haven't tried any of this btw, just thinking out loud.

Brian Armstrong