performance of bulk emailing using system net mail

Question

I have been asked to look into a bulk emailer for an intranet system and wanted some advice.

Currently we use System.Net.Mail and send the emails synchronously via the c

Answer 1

In your typical low volume scenario there are two computer systems that need to be considered here with regards to computing load.

1. The computer that is sending the emails (Normally a web server)
2. The Mail Server

Personally I see the Mail Server as somewhat of a black box. I do not worry about overloading it until it reports back an issue and then I adjust my email timeout or delay between sending emails or both.

The web server of course should not be bogged down with sending a huge number of emails and even worst the request thread should not be monopolized which would create another problem - scale. This therefore implies that non-threadpool threads should be used to handle the sending of the emails. Async/Await keywords springs to mind or the use of SmtpClient.SendAsync.

I believe both of these are compromises but still better than sending the emails synchronously. The web server should not be used at all to send large volumes of emails. This should be off-loaded to another computer(s) dedicated to this task.

• Application Server or
• Email Service

To get this scenario working, one approach requires a simple but reliable system of, persisting the email request to a queue (could be a simple database table) and having the application server (mail service) pop the queue on the other end.

So send asynchronously on a dedicated application server.

I still don't believe that's the end of it. How can you send large volumes of emails quickly. Spawning a 1000 threads might not work out so well on an 8-core computer. Therefore your code needs to be able to handle this scenario of effectively utilizing the available processing power when scheduling emails. There is a component that I use that handles this scenario perfectly - MassMailer.NET. It controls the number of threads and also supports in built and custom queues/repositories. Its built on top of two other components for Composing plus Sending Email and scheduling tasks on background threads.

The Business & Social side of things

The other thing to consider is whether you would want to include all the recipients in the TO field. While this takes the load off of the web server it complicates matters in the fact that everyone receiving the mail will have access to the list of recipients. For some business processes including marketing lists, this is a definite no no. Also when using this method internally it may result in more mails being sent later on as people click the Reply-To All button (this is of course very common in today's business environment).

Bulk TO Benefits

1. Takes the load off of the web server since its only required to send one email.

Bulk TO Drawbacks

1. Should not be used with some mailing lists due to conflicting business interests
2. Inadvertently results in mail server having to process more emails later due to the Reply-To All button.

Answer 2

Sending to a distribution list will be faster for the sender (you only send 1 email). However, the EMail server still has to send an email to all the users on that list, so it only saves 50% of the time.

However, large email lists do have drawbacks.