我应该将我的操作方法转换为异步操作方法吗？

Question

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

它运行良好但有时（每小时5-6次）用户必须等待比平时更多的转换才能进行....

我使用ASP.NET MVC，流程是： - USER 上传文件 - ＆gt;获取流并将转换为word - ＆gt; 保存 word文件作为临时文件 - ＆gt; 返回用户的网址

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

据我所知maxConcurrentRequestsPerCPU is 5000;还The default value of Threads Per Processor Limit is 25;所以这些默认设置应该更好，对吗？

那么为什么我的网络应用程序仍有＃34;等待＆＃34;有时候？我是否需要将任何IIS设置从默认设置修改为其他设置，或者我应该将转换的同步方法设置为异步？

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

更新：基本上对我来说不太清楚的是：如果用户上传文件且转换时间长，则不应该只有当前请求＆＃34;遭受＆ ＃34;因为这？因为下一个请求是独立的，所以进行另一个CPU调用和不同的线程，所以不应该在这里等待，不是吗？

Answer 1

这里有一些必须明确定义的事情。至少据我所知，Async（hronous）方法和流程并不是一回事。

异步方法（使用Task，通常还利用async / await关键字）将以下列方式工作：

1. 执行从线程t1开始，直到到达await
2. 线程t1上不会发生（可能）长操作 - 有时甚至根本不在应用程序线程上，利用IOCP（I / O完成端口）。
3. 线程t1是空闲的，并释放回线程池，并准备好在需要时为其他请求提供服务
4. 当（可能）长操作返回时，从线程池中取出一个线程（甚至可能是相同的t1，或者很可能是另一个），其余的代码执行从最后一次等待中恢复
5. 其余代码执行

这里有几点需要注意：

一个。客户端在整个过程中被阻止。最终切换线程等只发生在服务器上 湾这种方法主要用于缓解称为“线程饥饿”的不必要条件。它并不意味着加快客户端的总等待时间，而且通常不会加快这一过程。

据我所知，异步流程意味着，至少在这种情况下，在用户转换文档的请求之后，客户端（即客户端的浏览器）将很快收到响应，其中他是告知这个可能很长的过程已在服务器上启动，用户应该耐心等待，当前的响应页面可能会提供进度反馈。

在你的情况下，我推荐第二种方法，因为第一种方法根本没有帮助。

当然这并不容易。您需要模拟一个队列，您需要有一个处理代理和一个驱逐策略（如果您不想要第二个代理，则很可能由同一个代理执行）。

这将按以下方式工作：

一个。最终用户提交文件，Web服务器接收它 湾Web服务器将其放入队列并接收作业号 C。 Web服务器向用户返回一个带有作业号的响应（假设一个带有轮询机制的HTML页面，该页面将定期从服务器接收进度） d。代理将在有机会（即完成其他工作）时开始处理文档，并在公共场所更新其状态，以便Web服务器选择此信息 即Web服务器将接收来自HTML响应的调用，询问作业的状态，并会发现作业已完成并提供下载链接或直接开始下载。

这可以通过某种方式加以改进：

1. 代替客户端轮询服务器，可以使用websockets或长轮询（例如SignalR涵盖两者）
2. 如果硬件配置有意义，可以使用许多处理代理而不是一个

队列可以使用简单的RDBMS实现，RemusRuşanu有a nice article about this。