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

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

　　HTTP 双连接限制

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

　　线程池限制

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

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

　　该问题不仅限于 Web 服务

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

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

　　maxconnections

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

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

　　异步 Web 服务调用

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

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

' 错用同步 Web 服务调用所造成的性能极差的

' 页面！

Public Class SyncPage

Inherits System.Web.UI.Page

Protected WithEvents Label1 As System.Web.UI.WebControls.Label

Protected WithEvents Label2 As System.Web.UI.WebControls.Label

Private Sub Page_Load(ByVal sender As System.Object, _

ByVal e As System.EventArgs) Handles MyBase.Load

'调用 Web 服务

Dim proxy As New localhost.Service1

Label1.Text = proxy.Method1(500)

Label2.Text = proxy.Method1(200)

End Sub

End Class

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

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

Public Class AsyncPage

Inherits System.Web.UI.Page

Protected WithEvents Label1 As System.Web.UI.WebControls.Label

Protected WithEvents Label2 As System.Web.UI.WebControls.Label

Private Sub Page_Load(ByVal sender As System.Object, _

ByVal e As System.EventArgs) Handles MyBase.Load

'调用 Web 服务

Dim proxy As New localhost.Service1

Dim res As IAsyncResult

= proxy.BeginMethod1(500, Nothing, Nothing)

Dim res2 As IAsyncResult

= proxy.BeginMethod1(200, Nothing, Nothing)

Label1.Text = proxy.EndMethod1(res)

Label2.Text = proxy.EndMethod1(res2)

End Sub

End Class

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

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

[1] [2] 下一页  

[1] [2] 下一页