I'm having an issue sending large volumes of emails out from an ASP.Net application. I won't post the code, but instead explain what's going on. The code should send emails to 4000 recipients but seems to stall at 385/387.
我在从ASP.Net应用程序发送大量电子邮件时遇到问题。我不会发布代码,而是解释发生了什么。该代码应该发送电子邮件给4000个收件人,但似乎停在385/387。
The code creates the content for the email in a string.
代码以字符串形式创建电子邮件的内容。
It then selects a list of email address to send to.
然后,它会选择要发送到的电子邮件地址列表。
Looping through the data via a datareader it picks out the email address and sends an email.
通过数据加载器循环访问数据,它会选择电子邮件地址并发送电子邮件。
The email sending is done by a separate method which can handle failures and returns it's outcome.
电子邮件发送是通过一个单独的方法完成的,该方法可以处理故障并返回结果。
As each record is sent I produce an XML node in an XML document to log each specific attempt to send.
在发送每条记录时,我在XML文档中生成一个XML节点,以记录每个特定的发送尝试。
The loop seems to end prematurely and the XML document is saved to disk.
循环似乎过早结束,XML文档保存到磁盘。
Now I know the code works. I have run it locally using the same SMTP machine and it worked fine with 500 records. Granted there was less content, but I can't see how that would make any difference.
现在我知道代码有效了。我使用相同的SMTP机器在本地运行它,它可以正常工作500条记录。虽然内容较少,但我看不出这会有什么不同。
I don't think the page itself times out, but even if it did, I was sure .Net would continue processing the page, even if the user saw a page time out error.
我不认为页面本身超时,但即使它确实如此,我确信.Net会继续处理页面,即使用户看到页面超时错误。
Any suggestions appreciate because I'm pretty stumped.
任何建议都欣赏,因为我很难过。
4 个解决方案
#1
4
You're sending lots of emails. During the span of a single request? IIS will kill a request if it takes longer than a certain (configurable) amount of time.
你发送了很多电子邮件。在单个请求的范围内?如果请求花费的时间超过某个(可配置的)时间,IIS将终止该请求。
You need to use a separate process to do stuff like this. Whether that's a Timer you start from within global.asax, or a Thread which checks for a list of emails in a database/app_data directory, or a service you send a request to via WCF, or some combination of these.
你需要使用一个单独的过程来做这样的事情。无论是从global.asax开始的Timer,还是检查数据库/ app_data目录中的电子邮件列表的线程,或者是通过WCF发送请求的服务,还是这些的一些组合。
#2
2
The way I've handled this in the past is to queue the emails into a SQL Server table and then launch another thread to actually process/send the emails. Another aspx utility page can give me the status of the queue or restart the processing.
我过去处理这个问题的方法是将电子邮件排队到SQL Server表中,然后启动另一个线程来实际处理/发送电子邮件。另一个aspx实用程序页面可以为我提供队列状态或重新启动处理。
I also highly recommend that use an existing, legit, third-party mailing service for your SMTP server if you are sending mail out to the general public. Otherwise you run the risk of your ISP shutting off your mail access or (worse) your own server being blacklisted.
如果您要向公众发送邮件,我还强烈建议您为SMTP服务器使用现有的,合法的第三方邮件服务。否则,您将面临ISP关闭邮件访问权限的风险,或者(更糟糕的是)您自己的服务器被列入黑名单。
#3
0
If the web server has a timeout setting, it will kill the page if it runs too long.
如果Web服务器具有超时设置,则如果页面运行时间太长,它将终止该页面。
#4
0
I recommend you check the value of HttpServerUtility.ScriptTimeout - if this is set then when a script has run for that length of time, it will be shut down.
我建议您检查HttpServerUtility.ScriptTimeout的值 - 如果设置了这个值,那么当脚本运行了这段时间后,它将被关闭。
Something you could do to help is go completely old-school - combine some Response.Writes with a few Response.Flush to send some data back to the client browser, and this tends to keep the script alive (certainly worked on an old ASP.NET 1.1 site we had).
你可以做些什么来帮助完全老去 - 将一些Response.Writes和一些Response.Flush结合起来将一些数据发送回客户端浏览器,这往往会使脚本保持活力(当然可以在旧的ASP上运行)。我们有NET 1.1网站)。
Also, you need to take into account when this script is being run - the server may well also have been configured to perform an application reset (by default this is set to every 29 hours in IIS), if your server is set to something like 24 hours and this coincides with the time your script it run, you could be seeing that too - although the fact that the script's logging its response probably rules that out - unless your XML document is badly formed?
此外,您需要考虑何时运行此脚本 - 服务器也可能已配置为执行应用程序重置(默认情况下,此设置为IIS中每29小时),如果您的服务器设置为类似24小时,这与你的脚本运行的时间一致,你也可以看到它 - 尽管脚本记录其响应的事实可能会规则 - 除非你的XML文档形成错误?
All that being said, I'd go with Will's answer of using a seperate process (not just a thread hosted by the site), or as Bryan said, go with a proper mailing service, which will help you with things like bounce backs, click tracking, reporting, open counts, etc, etc.
总而言之,我会选择Will使用单独进程(不仅仅是网站托管的线程)的答案,或者正如Bryan所说的那样,选择合适的邮件服务,这将有助于您进行反弹,点击跟踪,报告,打开计数等等
#1
4
You're sending lots of emails. During the span of a single request? IIS will kill a request if it takes longer than a certain (configurable) amount of time.
你发送了很多电子邮件。在单个请求的范围内?如果请求花费的时间超过某个(可配置的)时间,IIS将终止该请求。
You need to use a separate process to do stuff like this. Whether that's a Timer you start from within global.asax, or a Thread which checks for a list of emails in a database/app_data directory, or a service you send a request to via WCF, or some combination of these.
你需要使用一个单独的过程来做这样的事情。无论是从global.asax开始的Timer,还是检查数据库/ app_data目录中的电子邮件列表的线程,或者是通过WCF发送请求的服务,还是这些的一些组合。
#2
2
The way I've handled this in the past is to queue the emails into a SQL Server table and then launch another thread to actually process/send the emails. Another aspx utility page can give me the status of the queue or restart the processing.
我过去处理这个问题的方法是将电子邮件排队到SQL Server表中,然后启动另一个线程来实际处理/发送电子邮件。另一个aspx实用程序页面可以为我提供队列状态或重新启动处理。
I also highly recommend that use an existing, legit, third-party mailing service for your SMTP server if you are sending mail out to the general public. Otherwise you run the risk of your ISP shutting off your mail access or (worse) your own server being blacklisted.
如果您要向公众发送邮件,我还强烈建议您为SMTP服务器使用现有的,合法的第三方邮件服务。否则,您将面临ISP关闭邮件访问权限的风险,或者(更糟糕的是)您自己的服务器被列入黑名单。
#3
0
If the web server has a timeout setting, it will kill the page if it runs too long.
如果Web服务器具有超时设置,则如果页面运行时间太长,它将终止该页面。
#4
0
I recommend you check the value of HttpServerUtility.ScriptTimeout - if this is set then when a script has run for that length of time, it will be shut down.
我建议您检查HttpServerUtility.ScriptTimeout的值 - 如果设置了这个值,那么当脚本运行了这段时间后,它将被关闭。
Something you could do to help is go completely old-school - combine some Response.Writes with a few Response.Flush to send some data back to the client browser, and this tends to keep the script alive (certainly worked on an old ASP.NET 1.1 site we had).
你可以做些什么来帮助完全老去 - 将一些Response.Writes和一些Response.Flush结合起来将一些数据发送回客户端浏览器,这往往会使脚本保持活力(当然可以在旧的ASP上运行)。我们有NET 1.1网站)。
Also, you need to take into account when this script is being run - the server may well also have been configured to perform an application reset (by default this is set to every 29 hours in IIS), if your server is set to something like 24 hours and this coincides with the time your script it run, you could be seeing that too - although the fact that the script's logging its response probably rules that out - unless your XML document is badly formed?
此外,您需要考虑何时运行此脚本 - 服务器也可能已配置为执行应用程序重置(默认情况下,此设置为IIS中每29小时),如果您的服务器设置为类似24小时,这与你的脚本运行的时间一致,你也可以看到它 - 尽管脚本记录其响应的事实可能会规则 - 除非你的XML文档形成错误?
All that being said, I'd go with Will's answer of using a seperate process (not just a thread hosted by the site), or as Bryan said, go with a proper mailing service, which will help you with things like bounce backs, click tracking, reporting, open counts, etc, etc.
总而言之,我会选择Will使用单独进程(不仅仅是网站托管的线程)的答案,或者正如Bryan所说的那样,选择合适的邮件服务,这将有助于您进行反弹,点击跟踪,报告,打开计数等等