MVC 3后台处理的利弊

Question

我需要在MVC 3应用程序中做一些音频处理，并想知道不同背景方法的利弊。音频处理作为一般规则将是一个长期运行的过程，因此我只想确保IIS可以自由地处理其他请求。

1. AsyncController &背景工作者 公共ActionResult GetAudioCompleted(byte[]音频){返回文件(音频，“音频/wav”，"mywavfile.wav")；}公开无效GetAudioAsync() { BackgroundWorker w=新的BackgroundWorker()；w.RunWorkerCompleted += (s，e) => {AsyncManager.Parameters“音频”= e.Result；e.Result }；w.DoWork += (s，e) => { byte[] b；使用(var ms =新的MemoryStream()) { //处理音频到内存流ms.Seek(0，SeekOrigin.Begin)；b=新的bytems.Length；ms.Read(b，0，(int)ms.Length)；e.Result = b；}；}
2. AsyncController &任务 公共ActionResult GetAudioCompleted(byte[]音频){返回文件(音频，“音频/wav”，"mywavfile.wav")；}公共无效GetAudioAsync() { byte[] var t= Task.Factory.StartNew(() => {byte[] b；使用(var ms =新MemoryStream()) { //处理音频到内存流ms.Seek(0，SeekOrigin.Begin)；b=新bytems.Length；ms.Read(b，0，(int)ms.Length)；}返回b；}) AsyncManager.OutstandingOperations.Decrement()；}(c => {AsyncManager.Parameters“AsyncManager.Parameters”= c.Result；c.Result })；}
3. 非异步控制器&线程 公共ActionResult GetaAudio() { byte[] b；使用(var ms =新的MemoryStream()) { var t=线程(() => { //处理音频到内存流} })；t.Start()；t.Join()；//错误检查等ms.Seek(0，SeekOrigin.Begin)；b=新bytems.Length；ms.Read(b，0，(int)ms.Length)；返回文件(b，“音频/wav”，"mywavfile.wav")；}

问题：

1. 推荐在web应用程序中使用BackgroundWorkers吗？
2. 如果我使用这些任务，这个后台线程是否使用IIS线程池中的一个线程(可能否定了这种方法的优点之一，因为线程不用于请求处理)？
3. 使用System.Threading.Thread -这个线程使用IIS线程池中的一个线程吗？t.Join()是否阻塞当前的IIS线程？

你觉得哪种方法更好，为什么呢？任何其他方法都是受欢迎的。

Answer 1

1. 不是的。ASP.NET和IIS在自己的线程上执行每个HTTP请求/响应。ASP.NET中的异步编程更多的是在每个请求中执行更多的工作(例如在不同的线程上执行无关的SQL查询)，而不是处理线程请求。
2. 我不知道，我对任务不太熟悉。
3. 是的，是的。

我会这样做(psuedocode)：

1. 我需要处理该文件，然后在后台线程(使用简单的System.Threading.Thread实例)中处理，这意味着instance/response线程不会被阻塞，并且可以立即将HTML返回给客户端。
2. 我会存储一个令牌或者引用到这个文件处理作业的某个地方。然后，我将返回一个303重定向到“/processingJobs/ job 123”(其中job123是作业ID)。
3. actionHandler for GET processingJobs将查找作业123的后台线程，并查看它是否已完成，如果未完成，则返回一个HTML，说明“您的作业正在处理，请再次刷新页面以获得更新的状态”，以及每5-10秒刷新一次页面的少量javascript。
4. 如果作业完成，则返回带有content-disposition:头的已处理音频文件。

如果音频处理是由单独的进程或队列系统来处理，而不是同时进行，则这种技术可以很好地扩展，甚至可以无限地扩展。

一般的指导方针是:如果HTTP请求/响应不能在100 be内完成，那么在后台执行任务，然后立即返回状态消息。