asp.net mvc 站点优化

基于上篇:IIS网站日志分析

现象

服务端：IIS 日志，

#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-taken

2017-02-07 04:26:43 10.173.17.106 POST /RunStatus/AddFlowMsg - 8088 - 10.165.124.2 - - 200 0 0 218

2017-02-07 04:26:53 10.173.17.106 POST /RunStatus/AddFlowMsg - 8088 - 10.171.127.232 - - 200 0 64 61094

客户端：爬虫异常日志，

The operation has timed out

由于爬虫设置超时时间为60秒，根据sc-win32-status：64 ， time-taken：61094

1. 客户端提前断开，就会看到scStatus=200，scwin32status=64
    2. 正常，我就会看到scStatus=200，scwin32status=0

可以看出：60秒后，客户端不愿意等了，所以请求超时。

分析：

真对上述问题，查看阿里云服务器状态：内存，CPU使用率都很低，由于是内网，带宽没问题。

什么原因呢？ 我觉得是服务器没利用起来。

后来找到这篇文章：https://msdn.microsoft.com/zh-cn/library/ee728598(v=vs.100).aspx

线程池处理请求的方式

 

 在 Web 服务器上，.NET Framework 维护一个用于服务 ASP.NET 请求的线程池。 当请求到达时，将调度池中的线程以处理该请求。 如果对请求进行同步处理，则在处理请求时将阻塞处理请求的线程，并且该线程不能对另一个请求提供服务。

这可能不是一个问题，因为线程池可以设置得足够大以容纳许多阻塞的线程。 但是，线程池中的线程数目是有限制的。 在同时处理多个长时间运行的请求的大型应用程序中，可能会阻塞所有可用的线程。 这种情况称为“线程不足”。 当出现这种情况时，Web 服务器会将请求排队。 如果请求队列已满，则 Web 服务器会拒绝请求并处于 HTTP 503 状态（服务器太忙）。

处理异步请求

 

 在可能出现线程不足的应用程序中，您可以配置通过异步方式处理操作。 异步请求与同步请求所需的处理时间相同。 例如，如果某个请求生成一个需要两秒钟来完成的网络调用，则该请求无论是同步执行还是异步执行都需要两秒钟。 但是，在异步调用的过程中，服务器在等待第一个请求完成的过程中不会阻塞对其他请求的响应。 因此，当有许多请求调用长时间运行的操作时，异步请求可以防止出现请求排队的情况。

在调用异步操作时，将执行以下步骤：

1. Web 服务器从线程池（辅助线程）获取一个线程并安排它处理传入请求。 此辅助线程启动一个异步操作。

2. 将此辅助线程返回到线程池以对另一个 Web 请求提供服务。

3. 在异步操作完成时通知 ASP.NET。

4. Web 服务器从线程池获取一个线程（可能是与启动异步操作的线程不同的线程）以处理请求的其余部分，包括呈现响应。

我的理解：

asp.net 线程池里面的线程数是固定的，我们把它们理解我服务台的窗口服务人员，

1，同步，它们既要接受客户端请求，又要处理业务。就如同窗口服务人员在等到客户办理业务时，自己去后面处理好在交给客户，一个人把一套流程走完。

2，异步，asp.net 线程池里面的线程只负责接受和应答。就如窗口人员等到客户来办理业务，然后给后台具体负责此业务的工作人员去处理，自己继续受理其它客户的业务，等到工作人员处理完了，再给任意一个

窗口服务人员，让他交给具体客户。

由上看出，我们把工作人员，及后台工作线程给利用起来了。

好了，那么我们就改成异步的吧，经过改造成异步控制器，CPU和内存立马飙上去了，再也没有客户端响应超时了  。