了解XMLHTTP异步调用WebService

简介

眼下AJAX炒的很火，它是javascript和xml的技术结合，异步交互、JavaScript脚本和XML封装数据是AJAX的三大特征。xmlhttp是ms几年前就有的技术了，近年也有不少相近的架构，上篇文章介绍了在客户端用脚本进行WebService调用，本文将重点了解异步调用。

异步 RPC

异步远程过程调用 (RPC) 是同步 RPC 机制的扩展。在同步 RPC 中，发出 RPC调用的线程将阻塞客户端，直到 RPC调用完成。异步 RPC 允许发出调用的线程继续执行，并且稍后再获取结果。同样，在异步 RPC 服务器上，即使在已调度的调用从应用程序代码返回到 RPC 运行时（管理器例程）后，逻辑 RPC 调用仍可继续进行

对于XMLhttp调用WebService,还需了解以下2点

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 个同时进行的请求即可用完全部线程，以后的请求必须排队等候。

重要信息：异步调用WebService时，请使用多线程编程技术。

异步WebService 调用时，如果不使用多线程技术，则在两个或多个线程同时尝试访问同一数据时，将会出现问题。原因就是上面的两个限制

性能和开销

异步调用实际上会使请求处理增加额外的开销，比同步调用要慢 20-30％。异步调用不应直接用作同步调用的替换方法。异步处理程序的用途是在该处理程序处理原始请求的同时，释放 ASP.NET 线程池线程以服务其他请求。只有在服务请求的工作需要大量非 CPU 绑定时间才能完成时，这一功能才有意义。例如，如果请求的完成取决于很多远程过程调用（或者 Web 服务调用）的完成，则适合于实现异步处理程序。如果生成异步处理程序以服务大量消耗 CPU 的请求，则只会增加与 ASP.NET 线程池线程竞争的线程，并且实际上可能会延长请求的总体处理时间。尽管就单个调用所用的时间而言，异步调用较慢，但若有效地使用（如使用重叠调用），则可以显著提高总的吞吐量。

简介

异步 RPC

HTTP 双连接限制

线程池限制

性能和开销

相关文章请参阅