asp.net-mvc - 我应该将我的操作方法转换为异步操作方法吗？

Question

我有一个网站，用户可以在其中上传PDF并将其转换为WORD文档。

它的工作原理不错，但有时(每小时5-6次)用户必须比平时等待更多时间才能进行转换...。

我使用ASP.NET MVC，流程为:
-USER 上载文件->获取流并将将转换为单词-> 将单词文件另存为临时文件-> 返回用户的网址

我不确定是否必须将此流转换为asynchronous吗？基本上，我的流程是顺序的，但是每秒大约有3-5个请求，CPU是双核和4 GB Ram。

据我所知maxConcurrentRequestsPerCPU is 5000;也The default value of Threads Per Processor Limit is 25;所以这些默认设置应该还不错吧？

那么，为什么我的Web应用程序仍然有些“等待”？是否需要将IIS设置从默认值修改为其他任何值，或者我应该使同步方法转换为异步方式？

Ps:转换本身需要1秒钟到40-50秒钟之间，具体取决于pdf文件的大小。

更新:基本上，对我来说不太清楚的是:如果用户上载文件并且转换很长，那么是否不应该仅使当前请求“受苦”？因为下一个请求是独立的，所以要进行另一个CPU调用和另一个线程，所以这里不应该等待，不是吗？

Answer 1

这里有几件事必须明确定义。至少据我所知，Async(hronous)方法和流程不是同一回事。

异步方法(使用Task，通常也利用async / await关键字)将以以下方式工作:

从线程t1开始执行，直到到达等待的

利用IOCP(I / O完成端口)，可能不会在线程t1上进行(可能)长时间的操作-有时甚至根本不在应用程序线程上进行。

线程t1是免费的，并释放回线程池，并准备在需要时为其他请求提供服务

当(可能)长操作返回一个线程时，该线程是从线程池中获取的(甚至可能是相同的t1或最有可能是另一个)，并且代码执行的其余部分将从上一次遇到的

继续执行

其余代码执行

这里有几件事要注意:

一种。客户端在整个过程中都处于阻塞状态。线程的最终切换等仅发生在服务器上
b。该方法主要旨在缓解称为“线程饥饿”的有害状况。这并不是要加快客户端的总等待时间，并且通常不会加快流程。

据我了解，至少在这种情况下，异步流程意味着，在用户请求转换文档之后，客户端(即客户端的浏览器)将迅速收到响应，在该响应中，他被告知服务器上可能已经开始了很长的过程，因此用户应耐心等待，当前响应页面可能会提供进度反馈。

对于您的情况，我建议使用第二种方法，因为第一种方法根本没有帮助。

当然，这并不容易。您需要模拟一个队列，您需要一个处理代理程序和一个逐出策略(如果您不希望使用第二个代理程序，则很有可能由同一代理程序强制执行)。

这将遵循以下几行:

一种。最终用户提交文件，Web服务器将其接收
b。 Web服务器将其放入队列中并接收作业号
C。网络服务器向用户返回带有作业编号的响应(例如，具有轮询机制的HTML页面，该机制会定期从服务器接收进度)
d。代理会在有机会时(即完成其他工作)开始处理文档，并在 public 位置更新其状态，以供Web服务器选择此信息。
e。 Web服务器将接收来自HTML响应的 call ，询问该作业的状态，并会发现该作业已完成，并提供下载链接或直接开始下载。

这可以通过一些方式进行完善:

可以使用websockets或长轮询(例如SignalR涵盖这两者)来代替客户端轮询服务器，而可以使用

如果硬件配置合理，可以使用许多处理代理代替一个处理代理


可以使用简单的RDBMS来实现该队列，Remus Rușanu具有a nice article about this。