在网站的优化过程中,我们分为两大部分:
1：页面前端优化,这里包括js脚本的合并及压缩,js事件的后绑定,图片与应用程序的分离等等,本篇文章并不讲前端优化。
2：服务端的优化。后台程序在执行时，一般比较耗时的就是些IO操作，数据库操作，或者是远程的服务等等。这里我想重点分析下对服务调用的优化问题。
异步调用服务的优势：可在硬件环境不改变的情况下适当的增加软件系统的吞吐量。
异步调用需要注意的地方：
1：并不是所有的服务都需要异步调用。
2：服务的异步调用并不会缩短服务的执行时间，它的优势在于可以和其它请求并行运算。
3：不适合的异步调用非担不会增加系统的吞吐量，反而会使系统性能下降。
4：服务的异步调用会增加客户端程序的复杂性。
我拿ASP.NET MVC页面的后台程序的生命周期来分析下服务的异步调用采用不同方法所产生的影响，异步处理举例:一个订单完成页需要有如下几个操作：
1：一个重量级请求，需要调用四次远程服务来完成用户客史的记录以及更新,如果同步调用需要2秒。
2：4个轻量级请求，花费0.5秒以下。
如果第一个请求采用同步方式调用，那么总共要花费： 2 + 0.5 + 0.5 + 0.5+0.5 = 4秒才能处理完所有请求。
如果使用了异步操作，第一个请求在请求远程服务之后会立即释放线程，然后在2秒内完成请求，此时其它的四个轻量级请求都处理完了。最后全部执行结束，第一个请求处理完毕。那么现在总共只花费了2秒钟。 异步操作提高系统并发能力的原因就在这。
问题:
1:耗时的操作需要尽可能放在所有任务的前面执行.否则起不到并发的效果。见下图:
2：异步的方法需要比其它方法耗时要长的多,否则非担不会提高系统的并发能力反而会使性能下降或者效果不显著，而且异步调用会使客户端程序复杂化。异步调用比起同步调用会增加额外的系统消耗，尽管很小。
3：异步操作对于单个用于异步的方法从执行时间上来说是没有任何节省的,它只是不堵塞主线程的执行,主线程的结束必须在异步方法返回结果后才能结束。下图是最佳的异步调用服务的场景。
4:异步服务调用时，我们一般都是利用回调函数来对结果进行操作，异步调用时BeginInvoke和EndInvoke是成对出现的，如果我们把回调方法设计成null,在BeginInvoke后立即进行EndInvoke，那么这种结果比同步调用性能更差，在实际项目中坚决不能出现类似这样的代码。
WCF服务优化：如果服务是WCF，而且客户端不太关心执行结果，那么我们可以针对这种情况把服务设计成单向操作类型。
WCF的单向操作:基于单向消息交换模式的服务调用和异步方式一样,但有不同,消息一旦进入网络传输层,就会返回。如果上面的客史同步调用需要2秒，那么单向操作可能只需要0.5秒以下。单向操作以后的过程和客户端没有任何关系了,客户端不会收到服务端的任何消息,即使服务揣抛出异常也不会影响客户端。
总结：服务的异步调用，需要根据当前应用场景来考虑是否采用，而且可以根据客户端对结果的关心程度，适当更改服务的设计来提高系统响应能力。同理，不合理的异步调用，首先会增加客户端程序的复杂性，而且有可能会影响系统性能。