减小字体
增大字体- ·上一篇文章：ASPX页Web服务调用性能优化(3)
- ·下一篇文章：ASPX页Web服务调用性能优化(1)
ASPX页Web服务调用性能优化(2)
应当注意的是，对本地计算机的连接数量从来都没有限制，因此，如果是连接到本地主机，则此设置无效。
maxWorkerThreads 和 minFreeThreads
如果收到 HTTP 503 错误（“服务暂时过载”），则表明线程池中的线程已全部占用，并且请求队列也已超出最大值（appRequestQueueLimit 的默认设置为 100）。对于 IIS 5.0 安装，可以简单地增加线程池的大小。而对于 IIS 6.0 安装（与 IIS 5.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 页面和 ASMX Web 服务请求。这有效地使 Web 服务器处理的同时请求数增加了一倍。在同时进行两个 Web 服务请求（使用异步 Web 服务调用）的情况下，我们最终使同时进行的请求数增加了两倍。为避免在回调本地计算机时出现此类问题，您应当考虑您的应用程序的体系结构，使其简单地直接从 ASPX 代码来执行 Web 方法中的代码。
Windows XP 限制
我们必须要注意，如果您在一个 Windows? XP 计算机上进行某项测试，则所面临的另一个限制是 XP Web 服务器对所允许的同时连接数的人为限制。因为 Windows XP 不是服务器平台，其同时连接数被限制为 10。这对于开发环境中的测试通常没问题，但是如果试图进行任何复杂的测试，该限制问题就会比较严重。本地计算机的连接不受此限制影响。
真正的解决方案：异步请求处理
调整配置设置是一种改善问题的方法，而在实际设计 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 秒钟才能完成。
做人要厚道，请注明转自chinazhan中国站长(www.ChinaZhan.com)。
maxWorkerThreads 和 minFreeThreads
如果收到 HTTP 503 错误（“服务暂时过载”），则表明线程池中的线程已全部占用，并且请求队列也已超出最大值（appRequestQueueLimit 的默认设置为 100）。对于 IIS 5.0 安装，可以简单地增加线程池的大小。而对于 IIS 6.0 安装（与 IIS 5.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 页面和 ASMX Web 服务请求。这有效地使 Web 服务器处理的同时请求数增加了一倍。在同时进行两个 Web 服务请求（使用异步 Web 服务调用）的情况下，我们最终使同时进行的请求数增加了两倍。为避免在回调本地计算机时出现此类问题，您应当考虑您的应用程序的体系结构，使其简单地直接从 ASPX 代码来执行 Web 方法中的代码。
Windows XP 限制
我们必须要注意，如果您在一个 Windows? XP 计算机上进行某项测试，则所面临的另一个限制是 XP Web 服务器对所允许的同时连接数的人为限制。因为 Windows XP 不是服务器平台，其同时连接数被限制为 10。这对于开发环境中的测试通常没问题，但是如果试图进行任何复杂的测试，该限制问题就会比较严重。本地计算机的连接不受此限制影响。
真正的解决方案：异步请求处理
调整配置设置是一种改善问题的方法，而在实际设计 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 秒钟才能完成。
做人要厚道，请注明转自chinazhan中国站长(www.ChinaZhan.com)。