由于已经接收了 .aspx 页面的数据，因此实际的页面处理也就非常简单了。

public class prerequesthandlerpage
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

label1.text = context.items("webserviceresult1")
label2.text = context.items("webserviceresult2")
end sub
end class

　　这不仅仅是理论 -- 它确实起作用！

　　如果不考虑我没有阻塞了所有线程，至少也使得浪费的资源更少了，因而这还是有意义的。但实际的结果确实会有所不同吗？答案是肯定的“是”！我把此专栏中介绍的三种测试情况放在了一起：从 web 页面代码进行 2 个阻塞的调用，从 web 页面代码进行 2 个异步调用，以及从 prerequesthandler 代码进行 2 个异步调用。我使用 microsoft application center test 对这三种情况进行了测试，在 60 秒钟内从 100 个虚拟客户端连续发送请求。下图显示的结果表明了在 60 秒钟内完成的请求数。
 

图 1：100 个同时进行请求的客户端在 60 秒钟内完成的请求

　　异步 prerequesthandler 方法处理的请求数大约是排在第二位的方法处理的请求数的 8 倍。因此，该方法使您可以处理更多请求，但是对于单个请求，实际要多长时间才能完成呢？下图显示了这三种方法的平均响应时间。


图 2：100 个同时进行请求的客户端的平均完成响应时间

　　使用 prerequesthandler 方法的平均请求响应时间仅为 3.2 秒。假设每个 web 服务调用的内置延迟为 3 秒钟，则该方法是一种非常有效的解决办法。

　　我必须指出，这些并非科学的数字是在我的并非科学的办公室中运行的并非科学的计算机上获得的。当然，如果将空闲的线程释放出来，让它们做一些实际的工作确实会改善性能，因而这也很有意义。希望这些结果能够表明性能的改善其实是非常显著的。

　　prerequesthandler 方法是很必要的，因为 .aspx 请求的处理程序中没有内置异步请求处理机制。但并非所有 asp.net http 处理程序都是这样。prerequesthandler 方法适用于所有 asp.net 请求类型，但使用将异步支持置于 .asmx 处理程序内的编程方式要比使用 prerequesthandler 编程方式更容易一些。

　　小结

　　无论何时遇到任何类型的进程耗时较长的性能问题，异步执行模型都是一个很好的方法。在从 .aspx 页面调用 web 服务的情况下，我们认为可以将异步 web 服务调用与 asp.net 提供的异步执行模式结合起来。这解决了在处理 .aspx 请求的过程中缺乏异步支持的问题。使用此异步方法可以消除性能问题以及线程池资源的消耗问题。

 

上一页 [1] [2] [3]

Tag: 性能优化

文章整理：iocblog
版权申明：本站文章均来自网络，如有侵权，请联系我们，我们收到后立即删除，谢谢！
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有。