Should I queue emails in a database before sending, instead of on the fly?

I'm developing a site that sends email notifications to users after certain events/user actions (tagged in a photo, added as a friend, etc.)

From my experience, sending emails from a web server can be slow. For instance when creating a new user I will send an email to confirm/welcome the account. However, there is short pause sometimes waiting for the page to load while it finishes sending the email.

My fear is that, if I ever have a problem connecting to a mail server or the mail server is overloaded, it will bottleneck my application/page loads

So my question is, what is the best way to send emails from a web application that sends emails on consistent basis?

Should I create a queue system, by storing email content in a database and then run scheduled cron jobs to process all the开发者_运维技巧 undelivered emails?

Or should I just send the email directly after a user completes an action/event (creating a member account, tagged in a photo, etc...)?

---

No. Ask your sysadmin to configure mail server. Correctly configured mail server should be faster then storing messages on database.

Use local sending to avoid network delays. [mail function] sendmail_path = /usr/sbin/sendmail in php.ini

It would work even if mail server is down (message will be queued).

---

Set up a mail relay on the local machine. That way you do not have to bother with cron and database storage of the mails, yet still prevent the overhead of immediate network traffic for every mail. On the downside you'll have to manage an additional daemon and you have to make sure you do not create an open relay.

---

Yes, set up a queue system by creating a mysql table that holds all necessary information and set a cron job to run every x minutes to select the emails from the queue and send them (don't forget to set a LIMIT for your sql query that fetches the emails for sending).

---

Db-solution you mention is fine

Simple solution would be to send mail as final action on script (when html has been sent),

Or configure php to use a less bogged down smtp, http://email.about.com/od/emailprogrammingtips/qt/Configure_PHP_to_Use_a_Remote_SMTP_Server_for_Sending_Mail.htm

regards, //t

---

As you said, you won't be sending emails synchronously with your web requests/responses - which is a good idea as you don't want your user experience blocking on something like connecting to a mail server. Even if it's a local mail server, it's always a good idea to make it async and decouple the two. In other words, your mails will be pushed into a queue like mechanism and sent async.

In this case, the advantage of persisting your to-be-sent messages in a database (or some other store) - as opposed to an in memory queue - is that you have more recoverability in case your webserver fails. You can always process persisted emails later, but if you have them in memory, any failure of your webserver process would mean losing the queued mails.