performance - 经典ASP-长时间运行的进程。为什么这样不好呢？

Question

我继承了一个非常古老的经典ASP脚本，该脚本曾经一次向大约5,000至10,000个收件人发送电子邮件，并且密件抄送数以百计。它位于具有高流量网站的专用服务器上。

邮件脚本的server.scripttimeout属性设置为10分钟，并将整个邮件列表加载到内存中的scripting.dictionary中，该脚本用于执行电子邮件验证和重复删除。

此脚本有可能同时被10到20个人使用，每个脚本最多发送10个电子邮件。

我觉得这对服务器不利，因为有可能同时运行多个长时间运行的进程，但是不能引用技术原因。这会导致线程阻塞或内存消耗问题吗？这可能会中断网站服务吗？

谁能给出任何技术原因，为什么这不是一个好主意？我认为此脚本应替换为邮件服务器，但是，我需要技术上的理由首先引用。

任何输入表示赞赏。

最好，
插口

编辑

具体而言，我认为每次运行此脚本时，ASP线程池中的线程都会忙于进行邮件发送。

根据http://www.iis.net/ConfigReference/system.webServer/asp/limits，processorThreadMax属性为:

“processorThreadMax属性指定最大数量的
IIS可能会为每个处理器创建工作线程。

注意:此设置会极大地影响您的可扩展性
Web应用程序和服务器的总体性能。
因为此属性定义了ASP请求的最大数量
可以同时执行，此设置应保留为默认值
除非您的ASP应用程序正在扩展调用
外部组件。”

假设有一个单处理器服务器，并且该值配置为默认值(25个线程)，那么我是否可以说如果20个并发用户同时执行邮件发送，则只有5个线程可用于网站服务？

如果我是正确的话，那么我认为仅凭这个理由就足以表明这种方法是不可持续的，应该用更耐用的方法代替。

谁能确认我是否正确？

Answer 1

需要考虑的几个原因:

如果在网站维护期间重新启动IIS服务/应用程序池该怎么办？

如果您的邮件发件人将消耗大量资源怎么办？

如果其他页面会占用大量资源(阻止邮件正常运行)怎么办？

PS:您现在如何运行脚本？如果通过转到浏览器中的特定页面来执行此操作，则还应考虑维护原因:浏览器很可能会通过超时取消请求，并且尽管可以解决各种问题(IIS取消脚本执行) ，不便的日志记录)，它仍然增加了很多缺点。