在 ASP.NET 中处理长时间运行的进程的常见方法
我们有一个长时间运行的数据传输过程，它只是一个被调用和运行的 asp.net 页面。最多可能需要几个小时才能完成。它似乎工作得很好，但我只是想知道有哪些更流行的方法来处理这样的漫长过程。您是否创建应用程序并通过 Windows 调度程序、Web 服务或自定义处理程序运行它？
We have a long running data transfer process that is just an asp.net page that is called and run. It can take up to a couple hours to complete. It seems to work all right but I was just wondering what are some of the more popular ways to handle a long process like this. Do you create an application and run it through windows scheduler, or a web service or custom handler?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
在一个用于 Web 应用程序中长时间运行任务的项目中，我创建了一个 Windows 服务。
每当用户必须执行耗时的任务时，IIS 会将任务交给服务，该服务将返回一个令牌（任务的临时名称），并且服务将在后台执行该任务。在任何时候，用户都可以看到他/她的任务的状态，这些任务要么在队列中待处理，要么已完成。该服务将并行执行固定数量的作业，并为下一个传入的任务保留一个队列。
In a project for long running tasks in web-application, i made a windows service.
whenever the user has to do the time-consuming task, the IIS would give the task to the service which will return a token(a temporary name for the task) and in the background the service would do the task. At anytime, the user would see the status of his/her task which would be either pending in queue, processing, or completed. The service would do a fixed number of jobs in parallel, and would keep a queue for the next-incoming tasks.
Windows 服务是典型的解决方案。您不想想要使用网络服务或自定义处理程序，因为这两者都会成为应用程序池回收的牺牲品，这会杀死您的进程。
A windows service is the typical solution. You do not want to use a web service or a custom handler as both of those will lie prey to the app pool recycling, which will kill your process.
Windows Workflow Foundation
我发现 WF 最吸引人的是工作流的设计并不复杂，在 SQL 中持久化服务器，这样如果服务器在进程中重新启动，工作流程就可以恢复。
Windows Workflow Foundation
What I find the most appealing about WF, is that workflows can be designed without much complexity to be persisted in SQL Server, so that if the server reboots in the middle of a process, the workflow can resume.
我根据 BA 的需要使用两种类型的流程。对于按需运行且可以定期安排的传输进程，我通常会编写一个接受命令行参数的 WinForms（这是个人偏好）应用程序，以便我可以使用参数安排作业或通过交互式窗口按需运行它。在过去的几年里，我已经编写了足够多的代码，因此我拥有了自己的基本通用 shell，我可以用它来创建这种性质的新应用程序。对于必须检测事件（文件夹中出现的文件、接收 CyberMation 调用或检测 SNMP 陷阱）的进程，我更喜欢使用 Windows 服务，以便它们始终可用。这有点棘手，因为您必须更加谨慎地对待内存使用、泄漏、回收、安全性等。对我来说，Windows 应用程序在长时间作业上的运行速度往往比通过 IIS 进程时运行得更快。我不知道这是否是因为它附加到 IIS 线程，或者它的内存/安全性是否更有限。我从来没有调查过。
我确实知道 .Net 应用程序提供了很大的灵活性和对资源的管理，并且通过一些标准和实践，它们可以相当快地推出并产生非常积极的结果。
I use two types of processes depending on the needs of my BAs. For transfer processes that are run on demand and can be scheduled regularly, I typically write a WinForms (this is a personal preference) application that accepts command line parameters so I can schedule the job with params or run it on demand through an interactive window. I've written enough of them over the last few years that I have my own basic generic shell that I use to create new applications of this nature. For processes that must detect events (files appearing in folders, receiving CyberMation calls, or detecting SNMP traps), I prefer to use Windows Services so that they are always available. It's a little trickier simply because you have to be much more cautious of memory usage, leaks, recycling, security, etc. For me, the windows application tends to run faster on long duration jobs than they do when through an IIS process. I don't know if this is because it's attached to an IIS thread or if its memory/security is more limited. I've never investigated it.
I do know that .Net applications provide a lot of flexibility and management over resources, and with some standards and practice, they can be banged out fairly quickly and produce very positive results.