这个问题与我最近问的一个连接重置问题有关。我也在追求这篇SO 文章和这篇SO 文章中的信息。我想知道的是追踪 IIS 线程池崩溃原因的最佳方法。我也在与我们的供应商一起解决这个问题。这是详细信息。
我有一个 IIS 应用程序。它使用一个非常简单的 ASP 页面，以我们的供应商提供的样本为模型，当我们几年前购买我们的第一个 COM 工具包时。此应用程序在 Windows Server 2003 上的 IIS 上运行。该应用程序是一个单独的 Web 服务，而不是虚拟根，并且它的端口号与 80 不同。换句话说，我们没有使用另一个 NIC 或虚拟 IP 地址。该站点的流量很少，但被配置为具有 DMZ。整个配置对我来说看起来有点时髦。
地址验证请求从使用 http 协议的无浏览器应用程序发送到 IIS 应用程序。街道号、街道名称、城市和州与其他一些标识一起发送，并发送回响应。其中一个应用程序是用 C 编写的；另一个是用 Clojure 编写的。
向新构建的 IIS 应用程序发送“单次”请求在两个应用程序中都可以正常工作。发送大量请求，很难确定是超过 25 还是其他数字，导致 IIS 线程池崩溃。这或多或少是错误日志所说的。
这个应用程序在 W2K/IIS 服务器上运行多年，没有发生任何事故。ASP 页面通过我们从供应商处购买的 COM 工具包与地址验证引擎对话。我们不得不升级到新的服务器（和 2012 COM 工具包），只是因为最新的 COM 工具包不会安装在 W2K 上，而且新的 COM 工具包包含对新的 USPS 地址验证规定的支持。在没有新工具包的情况下，我们将验证更少的地址，而您对地址进行条形码并获得折扣的唯一方法是验证地址。（当您发出 29,000 份机动车消费税账单时，折扣会有所帮助。）
追查此问题的最佳方法是什么，以便我找到罪魁祸首？我正在寻找与答案一样多的优质信息的链接。很抱歉含糊其辞；我知道 SO 的规则，并努力提供尽可能多的细节。如果有人想查看这些，我可以重新编辑这篇文章并提供日志条目。底线是我的 Clojure 客户端（处理批处理请求）在 IIS 线程池崩溃时开始重置并崩溃。
结语：
我们认为 COM 对象的快速打开和关闭是问题所在，并且我们以这种方式编写 ASP 页面得到了我们的供应商的认可。为了解决这个问题以及我们还需要安装 MS Access 来获得额外的地址验证功能这一事实，我们最终编写了一个 ActiveState Perl 程序来解决多种需求。
首先，我们购买了一个 ActiveState 产品，它将我们的 Perl 程序作为服务运行。该服务将以允许发送基于 http 的请求的参数和端口号开始，就像以前一样。在这种情况下，COM 对象将在 Perl 程序启动时打开一次，并在 Perl 程序退出时关闭。
Perl 程序提供的其他功能与本文无关，但编写此 Perl 程序消除了对旧配置所需的 IIS 和 MS Access 的需要。
所以，如果你想从这篇文章中得到一些东西，它会在打开程序时打开一个 COM 对象并在程序关闭时关闭，至少对于 W2K Server 2003 及更高版本。