批调用并不一定快

    ASP.NET AJAX的CTP版本（之前的版本）里有一个特性，就是允许在一个请求里包含多个请求。它工作时你不会注意到任何事情，而且也不需要写任何特殊的代码。一旦你使用了批调用特性，那么在一次批调用期间，其中所有的web service调用都会被执行，所以它将减少回发时间和总响应时间。

    实际的响应时间可能减少了，但是我们感觉到的延迟却变长了。如果有3个web service被批量调用，那么第一个调用不会最先完成，而是所有3个调用会在相同的时间完成。如果你的每一个web service调用完成后都更新UI的话，将不会一步一步更新，而是在所有调用一起完成后再一起更新UI。结果，你不会看到UI被快速更新，而是在UI被更新之前有一个长时间的延迟。如果说调用中的任何一个(比如第3个调用)下载了大量数据，那么在所有的3个调用完成之前用户不会看到任何变化。所以第一个调用的执行时间几乎接近3个调用的总执行时间。虽然减少了实际的总计处理时间，但是会感觉有更长的延迟。当每个调用都只传输少量数据的时候批调用是非常好的，这样，3个小型调用就会在一次回发中执行完。

    让我们看看3个调用是如何一个一个被完成的，这将说明这些调用实际上是如何被执行的。

    第二个调用到达服务端的时间要比第一个调用长，因为第一个调用吃光了带宽。同样的原因，下载也就会花更多的时间。浏览器同时打开了两个连接到服务器端的连接，所以在同一时间，只能处理两个调用。一旦第一个调用或第二个调用完成后，第三个调用才能被处理。

    当3个web service在一次请求中被批调用的时候：



    这里总计下载时间将会有所减少（如果IIS的压缩功能启用的话），并且只需一次网络响应。所有的3个调用一次被发往到服务端后全部执行，组合而成的三个调用的响应是在一次调用中下载。但是对于用户来讲，他们会感觉速度变慢了，因为UI的更新发生在所有批调用完成之后。这个批调用完成的总时间总是要长于两个调用的。并且，如果你有大量的一个又一个的UI更新，IE将会冻结一段时间，这将给用户带来一个糟糕的体验。一些时候，时间较长的UI更新会导致浏览器出现“白屏”，但是FireFox和Opera不会有此问题。

    批调用也是有一些优点的。如果你的IIS启用了gzip压缩功能的话，将对全部结果进行压缩而不是分别压缩每个结果，那么总下载时长就会少于单独调用的下载时长。所以，通常批调用都是一些小型调用的话会比较好。但是如果调用会发送或者返回较大数据的话，比如20KB，那么最好就别使用批调用了。批调用还有另一个问题，比如说前两个调用非常小，第3个调用十分大，如果这3个调用被批调用的话，那么前两个小的调用就要延迟很长时间，因为第3个很大。