ASPX页Web服务调用性能优化

摘要：本文介绍了如何通过异步方法消除使用MicrosoftASP.NET的Web服务调用的性能问题和线程池资源的消耗问题。

情况：从ASP.NET页面调用Web服务时的性能破坏

我们在本文中讨论Web服务时，期望在各种情况下都可以享用Web服务。一个主要的情况是从中间层环境（如ASP.NETWeb页面）访问Web服务。为MapPoint.NETWeb服务的用户提供支持的人员经常收到这样的问题，即用户在使用其Web服务时，对MapPoint.NET的调用可能需要相当长的时间。这本身并不是什么问题，但某些其他因素可以使之成为比表面上要严重得多的大问题。

HTTP双连接限制

HTTP规范表明，一个HTTP客户端与任一服务器最多可以同时建立两个TCP连接。这可以防止单个浏览器在浏览某个页面（例如，具有120个嵌入的缩略图）时，由于连接请求过多而使服务器负载过重。此时，浏览器将仅创建2个连接，然后通过这两个管道开始发送120个HTTP请求，而不是创建120个TCP连接并通过每个连接来发送HTTP请求。对于中间层，此方法的问题在于，中间层可能会有50个同时请求连接的用户。如果不得不为每个用户进行一次MapPoint.NETWeb服务调用，将会有48个用户等待两个管道中的一个空闲下来。

线程池限制

ASP.NET处理传入的请求的方式是通过一个称为进程线程池的一组线程为其提供服务。正常情况下，请求传入后，池中某个空闲的线程将为其提供服务。这里的问题在于，进程线程池不会创建无数个线程来处理大量的请求。具有最大线程数限制是一件好事，因为如果我们无限地创建线程，计算机上的全部资源将只能用来管理这些线程了。通过限制所能创建的线程数，我们可以把线程管理的系统开销保持在一个可控的水平。如果某个请求传入时线程池中的所有线程都被占用，则该请求将排队等候，在忙线程完成任务后，空闲出来的线程才能处理新请求。此方法实际上比切换到某个新线程更有效，因为不需要在请求之间进行线程切换。但存在的问题是，如果线程的使用效率不高（尤其是在非常忙的Web服务器上），则等候的请求队列会变得很大。

考虑一下从ASP.NET页面进行Web服务调用的情况。如果进行同步调用，则正在运行的线程将被阻塞，直到Web服务调用完成为止。在调用期间，线程无法进行任何其他活动。它无法处理其他请求，只能等待。如果某个单处理器计算机上具有默认的工作线程数20，则只需20个同时进行的请求即可用完全部线程，以后的请求必须排队等候。

该问题不仅限于Web服务

不仅调用Web服务的用户会遇到从Web页面进行调用时的拥堵且耗时较长的问题。进行任意数量的较长的调用都会遇到同样的问题，例如：SQLServer?请求、长文件的读取或写入、各种Web请求或访问某个并发资源（其中锁定会造成严重的延迟）。实际上，有许多使用Web服务的情况，其服务调用比较迅速，并不是什么问题。但您或许会理解，如果您想通过代理服务器调用MapPoint.NETWeb服务，所使用的连接具有一定的延迟，同时相应的服务可能又要花费一些时间来处理请求，则您可能在各处位置都看到延迟的情况，并且如果站点很忙，便可能出现问题。

改善问题
　
该问题的某些方面可以通过对环境进行某些配置设置来改善。我们看一下可用于改善该问题的某些配置设置。

maxconnections

连接到Web资源的默认双连接限制可以通过一个名为connectionManagement的配置元素来控制。connectionManagement设置允许您添加要让其采用非默认连接限制的站点的名称。可以将以下内容添加到典型的Web.config文件中，将您连接的所有服务器的连接限制默认值增加到40。

＜configuration＞
＜system.net＞
＜connectionManagement＞
＜addaddress="*"maxconnection="40"/＞
＜/connectionManagement＞
＜/system.net＞

＜system.web＞
...

应当注意的是，对本地计算机的连接数量从来都没有限制，因此，如果是连接到本地主机，则此设置无效。

maxWorkerThreads和minFreeThreads

如果收到HTTP503错误（“服务暂时过载”），则表明线程池中的线程已全部占用，并且请求队列也已超出最大值（appRequestQueueLimit的默认设置为100）。对于IIS5.0安装，可以简单地增加线程池的大小。而对于IIS6.0安装（与IIS5.0不兼容），这些设置将无效。

maxWorkerThreads和maxIoThreads分别控制工作线程数以及处理新提交的ASP.NET请求的线程数。这些设置需要在您的Machine.config中进行配置，它们将影响您计算机上运行的所有Web应用程序。maxWorkerThreads是Machine.config中的processModel元素的一部分，并且您在查看后会发现，该设置的默认值为每个处理器20个线程。

minFreeThreads设置可以在Machine.config中进行配置，或者在您的应用程序的Web.config文件中的httpRuntime元素下进行配置。该设置的作用是，当空闲的线程数低于所设置的限制时，将禁止使用线程池中的线程来处理传入的HTTP请求。如果您需要某个进程线程池线程完成挂起的请求，这会很有用。如果所有的线程都被用来处理传入的HTTP请求，并且这些请求在等待另一个线程完成其处理，那么就会进入死锁状态。例如，如果您正在从ASP.NET应用程序进行对某个Web服务的异步Web服务调用，并且在等待回调函数完成该请求，就会出现这种情况。因为回调必须在进程线程池中的空闲线程上进行。如果查看一下您的Machine.config，将会注意到minFreeThreads设置的默认值为8，如果工作线程池的限制为20，则该默认值还可以满足需要，但是，如果线程池的大小增加到100，该默认值就太小了。

应当注意的是，如果您的ASP.NET应用程序对本地计算机进行Web服务调用，则线程池限制的问题将被激化。例如，我为此专栏创建的测试应用程序调用与ASPX页面同处一台计算机上的Web服务。因而，对于阻塞的调用，一个线程被同时用于ASPX页面和ASMXWeb服务请求。这有效地使Web服务器处理的同时请求数增加了一倍。在同时进行两个Web服务请求（使用异步Web服务调用）的情况下，我们最终使同时进行的请求数增加了两倍。为避免在回调本地计算机时出现此类问题，您应当考虑您的应用程序的体系结构，使其简单地直接从ASPX代码来执行Web方法中的代码。

WindowsXP限制

我们必须要注意，如果您在一个Windows?XP计算机上进行某项测试，则所面临的另一个限制是XPWeb服务器对所允许的同时连接数的人为限制。因为WindowsXP不是服务器平台，其同时连接数被限制为10。这对于开发环境中的测试通常没问题，但是如果试图进行任何复杂的测试，该限制问题就会比较严重。本地计算机的连接不受此限制影响。

真正的解决方案：异步请求处理

调整配置设置是一种改善问题的方法，而在实际设计Web应用程序时通过某种方式彻底解决问题则是另一回事。等待阻塞的调用完成的线程永远也不会有更好的调整余地，因此，解决的办法是完全避免阻塞问题。异步处理请求就是一个适当的解决方案。这表现在两个方面：进行异步Web服务调用，以及在ASP.NETWeb应用程序中异步处理请求。

异步Web服务调用

在以前的专栏中，我写了有关异步调用Web服务的问题。能够使线程不用等待Web服务调用完成是创建释放线程以便处理更多请求的异步页面处理模型的关键部分。此外，异步调用Web服务也比较简单。

请考虑以下ASPX页面的VisualBasic.NET代码：

'错用同步Web服务调用所造成的性能极差的
'页面！
PublicClassSyncPage
InheritsSystem.Web.UI.Page

ProtectedWithEventsLabel1AsSystem.Web.UI.WebControls.Label
ProtectedWithEventsLabel2AsSystem.Web.UI.WebControls.Label

PrivateSubPage_Load(ByValsenderAsSystem.Object,_
ByValeAsSystem.EventArgs)HandlesMyBase.Load
'调用Web服务
DimproxyAsNewlocalhost.Service1
Label1.Text=proxy.Method1(500)
Label2.Text=proxy.Method1(200)
EndSub

EndClass

此代码非常易懂。页面加载时将创建一个Web服务代理实例，然后用该实例两次调用一个名为Method1的Web方法。Method1只返回包含传递给该方法的输入参数的字符串。为了向该系统添加一定程度的延迟，Method1在返回字符串之前还休眠了3秒钟。从调用返回到Method1的字符串被放在ASPX页面上的两个标签的文本中。该页面提供的性能极差，并且像一块海绵一样从进程线程池中吸取线程。由于在Method1Web方法中有3秒钟的延迟，对该页面的一个调用至少要6秒钟才能完成。

以下代码片段显示了一个类似Web页面的代码，只不过现在进行的是异步Web服务调用。

PublicClassAsyncPage
InheritsSystem.Web.UI.Page

ProtectedWithEventsLabel1AsSystem.Web.UI.WebControls.Label
ProtectedWithEventsLabel2AsSystem.Web.UI.WebControls.Label

PrivateSubPage_Load(ByValsenderAsSystem.Object,_
ByValeAsSystem.EventArgs)HandlesMyBase.Load
'调用Web服务
DimproxyAsNewlocalhost.Service1
DimresAsIAsyncResult
=proxy.BeginMethod1(500,Nothing,Nothing)
Dimres2AsIAsyncResult
=proxy.BeginMethod1(200,Nothing,Nothing)
Label1.Text=proxy.EndMethod1(res)
Label2.Text=proxy.EndMethod1(res2)
EndSub

EndClass

同样，该页面将创建一个Web服务代理，然后两次调用Method1Web方法。不同的是，现在调用的是BeginMethod1，而不是直接调用Method1。BeginMethod1调用将立即返回，这样我们就可以开始第二次调用该方法。与第一个示例中等待第一个Web服务调用完成不同，现在我们可以同时开始这两个调用。对EndMethod1的调用只是在特定的调用完成前会造成阻塞。

值得注意的是，当我们从ASPX页面返回后，响应将发送给客户端。因此，在获得所需的数据之前，我们无法从Page_Load方法返回。这就是我们要阻塞Web服务调用直至其完成的原因。好的方面是两个调用可以同时执行，因此先前6秒钟的延迟现在将降到3秒钟左右。这虽然好一些，但仍然创建了阻塞的线程。我们真正需要的是在完成Web服务调用的同时，能够释放线程以便其处理HTTP请求。问题在于，ASPX页面的处理模型没有一个异步执行模式。不过，ASP.NET确实提供了一个解决此问题的方法。

异步PreRequestHandler执行

ASP.NET支持称为HttpHandlers的类。HttpHandlers是实现IHttpHandler接口的类，用于为带有特定扩展名的文件的HTTP请求提供服务。例如，如果查看一下Machine.config文件，您将注意到，有许多HttpHandlers服务于带有扩展名（如.asmx、.aspx、.ashx甚至.config）的文件的请求。对于带有特定扩展名的文件的请求，ASP.NET将查看其配置信息，然后调用与其相关联的HttpHandler为该请求提供服务。

ASP.NET还支持写事件处理程序，在处理Http请求过程中的各个时候都可以发生这类事件。其中一个事件是PreRequestHandlerExecute事件，它恰好发生在某个特定请求的HttpHandler被调用之前。还有一个对PreRequestHandlerExecute通知的异步支持，可以注册这些通知以使用HttpApplication类的AddOnPreRequestHandlerExecuteAsync方法。HttpApplication类源自基于Global.asax文件创建的事件处理程序。我们将使用异步PreRequestHandler选项为Web服务调用提供异步执行模式。

在调用AddOnPreRequestHandlerExecuteAsync之前要做的第一件事是创建一个BeginEventHandler和一个EndEventHandler函数。请求传入后，将调用BeginEventHandler函数。我们将在此时开始异步Web服务调用。BeginEventHandler必须返回一个IAsyncResult接口。如果您正在进行一个Web服务调用，则可以只返回由Web服务begin函数返回的IAsyncResult接口（在我们的示例中，将由BeginMethod1方法返回一个IAsyncResult接口）。在我创建的示例中，我想执行与前面的Web页面示例（其中揭示了同步和异步Web服务调用）相同的操作。这就意味着我必须创建自己的IAsyncResult接口。我的BeginEventHandler代码如下所示：

PublicFunctionBeginPreRequestHandlerExecute(
ByValsenderAsObject,_
ByValeAsEventArgs,_
ByValcbAsAsyncCallback,_
ByValextraDataAsObject)AsIAsyncResult
IfRequest.Url.AbsolutePath_
="/WebApp/PreRequestHandlerPage.aspx"Then
DimproxyAsMyProxy=NewMyProxy
proxy.Res=NewMyAsyncResult
proxy.Res.result1
=proxy.BeginMethod1(_
500,_
NewAsyncCallback(AddressOfMyCallback),_
proxy)
proxy.Res.result2
=proxy.BeginMethod1(_
300,_
NewAsyncCallback(AddressOfMyCallback),_
proxy)
proxy.Res.Callback=cb
proxy.Res.State=extraData
proxy.Res.Proxy=proxy
Returnproxy.Res
EndIf
ReturnNewMyAsyncResult
EndFunction

关于此代码还有许多有趣的事情值得注意。首先，针对此虚拟目录处理的每个HTTP请求都将调用此代码。因此，我做的第一件事就是检查请求的实际路径，查看它是否是我要为其提供服务的页面的路径。

我的函数使用了一些有趣的输入参数来调用。cb参数是ASP.NET传递给我的回调函数。ASP.NET希望在我的异步工作完成后，可以调用由它提供给我的回调函数。它们就是通过这种方式知道何时调用我的EndEventHandler。同样，如果我只进行一个Web服务调用，则只需将回调传递给BeginMethod1调用，然后Web服务调用将负责调用函数。但在本例中，我进行了两个单独的调用。因此，我创建了一个传递给两个BeginMethod1调用的中间回调函数，并且在回调代码中检查两个调用是否都已完成。如果没完成，我将返回；如果已完成，我将调用原始的回调。另一个有趣的参数是extraData参数，它在ASP.NET调用我时为ASP.NET保存了状态。我在调用由cb参数指定的回调函数时必须返回该状态信息，因此，我将其存储在所创建的IAsyncResult类中。我的回调代码如下所示：

PublicSubMyCallback(ByValarAsIAsyncResult)
DimproxyAsMyProxy=ar.AsyncState
Ifproxy.Res.IsCompletedThen
proxy.Res.Callback.Invoke(proxy.Res)
EndIf
EndSub

还应当提到的一点是，我创建的实现IAsyncResult的类（称为MyAsyncResult）将在查询IsCompleted属性时检查两个挂起Web服务调用的完成情况。

在EndEventHandler中，我只是从Web服务调用获取结果，然后将其存储在当前的请求上下文中。该上下文与要传递给HttpHandler的上下文相同。在本例中，它是.aspx请求的处理程序，这样它便可以用于我的标准代码。我的EndEventHandler代码如下所示：

PublicSubEndPreRequestHandlerExecute(ByValarAsIAsyncResult)
IfRequest.Url.AbsolutePath_
="/WebApp/PreRequestHandlerPage.aspx"Then
DimresAsMyAsyncResult=ar
DimproxyAsMyProxy=res.Proxy
DimretStringAsString
retString=proxy.EndMethod1(proxy.Res.result1)
Context.Items.Add("WebServiceResult1",retString)
retString=proxy.EndMethod1(proxy.Res.result2)
Context.Items.Add("WebServiceResult2",retString)
EndIf
EndSub

由于已经接收了.aspx页面的数据，因此实际的页面处理也就非常简单了。

PublicClassPreRequestHandlerPage
InheritsSystem.Web.UI.Page

ProtectedWithEventsLabel1AsSystem.Web.UI.WebControls.Label
ProtectedWithEventsLabel2AsSystem.Web.UI.WebControls.Label

PrivateSubPage_Load(ByValsenderAsSystem.Object,_
ByValeAsSystem.EventArgs)HandlesMyBase.Load

Label1.Text=Context.Items("WebServiceResult1")
Label2.Text=Context.Items("WebServiceResult2")
EndSub
EndClass

这不仅仅是理论--它确实起作用！

如果不考虑我没有阻塞了所有线程，至少也使得浪费的资源更少了，因而这还是有意义的。但实际的结果确实会有所不同吗？答案是肯定的“是”！我把此专栏中介绍的三种测试情况放在了一起：从Web页面代码进行2个阻塞的调用，从Web页面代码进行2个异步调用，以及从PreRequestHandler代码进行2个异步调用。我使用MicrosoftApplicationCenterTest对这三种情况进行了测试，在60秒钟内从100个虚拟客户端连续发送请求。下图显示的结果表明了在60秒钟内完成的请求数。

图1：100个同时进行请求的客户端在60秒钟内完成的请求

异步PreRequestHandler方法处理的请求数大约是排在第二位的方法处理的请求数的8倍。因此，该方法使您可以处理更多请求，但是对于单个请求，实际要多长时间才能完成呢？下图显示了这三种方法的平均响应时间。

图2：100个同时进行请求的客户端的平均完成响应时间

使用PreRequestHandler方法的平均请求响应时间仅为3.2秒。假设每个Web服务调用的内置延迟为3秒钟，则该方法是一种非常有效的解决办法。

我必须指出，这些并非科学的数字是在我的并非科学的办公室中运行的并非科学的计算机上获得的。当然，如果将空闲的线程释放出来，让它们做一些实际的工作确实会改善性能，因而这也很有意义。希望这些结果能够表明性能的改善其实是非常显著的。

PreRequestHandler方法是很必要的，因为.aspx请求的处理程序中没有内置异步请求处理机制。但并非所有ASP.NETHTTP处理程序都是这样。PreRequestHandler方法适用于所有ASP.NET请求类型，但使用将异步支持置于.asmx处理程序内的编程方式要比使用PreRequestHandler编程方式更容易一些。

小结

无论何时遇到任何类型的进程耗时较长的性能问题，异步执行模型都是一个很好的方法。在从.aspx页面调用Web服务的情况下，我们认为可以将异步Web服务调用与ASP.NET提供的异步执行模式结合起来。这解决了在处理.aspx请求的过程中缺乏异步支持的问题。使用此异步方法可以消除性能问题以及线程池资源的消耗问题。