我被要求研究一个用于 Intranet 系统的批量电子邮件，并希望得到一些建议.
I have been asked to look into a bulk emailer for an intranet system and wanted some advice.
目前我们使用 System.Net.Mail 并通过客户自己的 smtp 服务器(通常是 Microsoft Exchange)同步发送电子邮件.
Currently we use System.Net.Mail and send the emails synchronously via the customers own smtp server, typically Microsoft exchange.
如果我们允许他们向越来越大的群体发送电子邮件，我可能会遇到什么样的陷阱?我考虑过我可能需要考虑异步发送它们，将一封电子邮件发送到大型分发列表而不是发送给每个收件人的电子邮件是否更快.
If we were allow them to send emails to larger and larger groups what sort of pitfalls will I likely face? I have considered that I may need to look at sending them asynchronously, is it quicker to send one email to a large distribution list rather than an email to each recipient.
任何建议将不胜感激
在典型的低容量场景中，有两个计算机系统需要在此处考虑计算负载.
In your typical low volume scenario there are two computer systems that need to be considered here with regards to computing load.
我个人认为邮件服务器有点像一个黑盒子.我不担心它会过载，直到它报告问题然后我调整我的电子邮件超时或发送电子邮件之间的延迟或两者兼而有之.
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.
Web 服务器当然不应该因为发送大量电子邮件而陷入困境，更糟糕的是，请求线程不应该被垄断，这会产生另一个问题 - 规模.因此，这意味着应该使用非线程池线程来处理电子邮件的发送.Async/Await 关键字浮现在脑海中或使用 SmtpClient.SendAsync.
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.
我相信这两者都是妥协，但仍然比同步发送电子邮件要好.根本不应该使用 Web 服务器来发送大量电子邮件.这应该被卸载到另一台专门用于此任务的计算机上.
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.
为了让这个场景工作，一种方法需要一个简单但可靠的系统，将电子邮件请求持久化到一个队列(可能是一个简单的数据库表)，并让应用程序服务器(邮件服务)在另一端弹出队列.
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.
所以在专用应用服务器上异步发送.
我仍然不相信这就是结局.如何快速发送大量电子邮件.在 8 核计算机上生成 1000 个线程可能效果不佳.因此，您的代码需要能够处理这种在安排电子邮件时有效利用可用处理能力的场景.我使用的一个组件可以完美地处理这种情况 - MassMailer.NET.它控制线程数，还支持内置和自定义队列/存储库.它建立在 撰写和发送电子邮件 和调度任务的两个组件之上在后台线程上.
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.
商业与社会方面
要考虑的另一件事是您是否希望在收件人"字段中包含所有收件人.虽然这减轻了 Web 服务器的负载，但由于每个接收邮件的人都可以访问收件人列表这一事实，事情变得复杂了.对于包括营销列表在内的某些业务流程，这是绝对不行的.此外，在内部使用此方法时，可能会导致稍后发送更多邮件，因为人们单击全部回复"按钮(这在当今的商业环境中当然很常见).
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).
批量受益
散装缺点
这篇关于使用系统网络邮件的批量发送电子邮件的性能的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持跟版网！