这个问题是关于ASP.NET对我施加的限制（如脚本超时等）。
我有一个在ASP.NET下运行的服务，我想创建一个用于监控的对应服务。
主要服务的数据位于数据库中 我正在考虑让监视服务在一个循环内以1秒为间隔查询数据库，由远程客户端完成的http请求发出。 现在，这个监视的实际服务将由客户端http请求完成，这将使脚本循环（用C＃编写），当检测到新数据时，它会将该数据聚合到那个循环请求输出缓冲区中，发送它，并退出循环，从而完成请求 客户端必须发出新请求才能继续获取更新。
这实际上就像TCP（就像Windows IOCP一样）;您为数据请求服务并等待它。当它到达时，你发出另一个请求。
我的实际问题是：你以前做过吗？怎么回事？我是否受到IIS / ASP.NET框架强加的某些（可配置）限制的限制？ 在这种情况下我有哪些限制，或者，如果没有太多复杂的事情，有什么更好的选择？
请注意，我不希望一次有多个这样的监控请求，可能是几十个 这意味着10个这样的并发监视请求将使10个线程忙，问题是;它会伤害IIS /性能吗？ IIS如何处理10个忙线程？会发出更多吗？有什么限制？这只是我能想到的限制的一个例子。
答案 0 :(得分：1)
我认为你在这种情况下主要担心的是超时，这几乎是可配置的。但我认为这是一个错误的解决方案 - 您可以更好地使用一些后台服务，不断/定期运行，并将监控数据写入某个数据存储，然后您的监控页面将根据请求返回它。
如果您希望页面仅在monitorign数据可用时显示某些内容 - 使用ajax实现它 - 在页面加载查询监视服务上，那么如果有一些监视事件可用 - 如果没有 - 再次进行睡眠和查询则渲染它们。
IMO这将是一个比长期运行的请求更好的解决方案。
答案 1 :(得分：0)
我认为使用ASP.NET监控服务不是一个好主意，原因如下......
当您的应用程序池崩溃时会发生什么？
如果您决定执行IISReset怎么办？首先出现哪个应用程序......主应用程序或监控应用程序？
如果监控应用程序因负载而挂起怎么办？
如果主服务上的负载已经很高，该怎么办？不会每隔1秒监控一次，增加主服务以及IIS的负载？
你明白了......