We are currently sending emails to users asynchronoulsy using the ThreadPool. Essentially, we have logic that comes down to this:
for (int i=0 < i < numUsers; i++)
{
//Pre email processing unrelated to sending email
string subject = GetSubject();
string message = GetMessage();
string emailAddress = GetEmailAddress();
EmailObj emailObj = new EmailObj { subject = subject, message = message, emailAddress = emailAddress };
bool sent = ThreadPool.QueueUserWorkItem(new WaitCallback(SendEmail), emailObj);
//Post email processing unrelated to sending email
}
public void SendEmail(object emailObj)
{
//Create SMTP client object
SmtpClient client = new SmtpClient(Configuration.ConfigManager.SmtpServer);
//Logic to set the subject, message etc
client.Send(mail);
}
The logic works great so far with a low number of users. We are trying to scale this to be able to send a million or so emails.
Per MSDN, the maximum number of thread pool threads is based on memory and according to this SO answer, for a 64 bit architecture, it appears that the maximum number of thread pool threads is 32768.
Does this mean, that as long as the number of emails we send out at a time is < 32768, we should be fine? What happens when this number is exceeded? What happens when the SMTP service is turned off or there’s a delay in sending an email, will the thread pool thread wait until the email is sent?
When the number of threads exceed the threshold, does the section marked //Post email processsing unrelated to sending email get executed at all?
Any explanations are really appreciated.
Threads have overhead – 1MB of thread local storage. You would never want to have 32K threads in your thread pool. A thread pool is used to gate and share threads because they have overhead. If the thread pool gets saturated, future calls are queued and wait for an available thread in the pool.
Another thing to consider is SMTP servers are asynchronous (drop in outbound folder). Also, as someone above mentioned, it can be a bottle neck.
One option is to increase the throughput by increasing the number of ‘agents’ sending mails and increase the number of SMTP servers to scale out the solution. Being able to independently scale out the agents and the SMTP servers allows you to address the bottleneck.