OA自动化NETRS性能分析及利用L进行性能测试的方案.docxVIP

OA自动化NETRS性能分析及利用L进行性能测试的方案

.NETRemotingServer性能分析及利用Loadrunner进行性能测试的方案

1概述

.NETRemoting被誉为管理应用程序域之间的RPC的首选技术。应用程序域是公共语言运行库的隔离单元，它们是在进程内创建并运行的。这与CLR和非CLR托管的进程之间的进程间通信（互操作）不同。后一种类型的RPC通信（特别是Web上的）一般被认为是Web服务领域的问题。遗憾的是，这种看似清楚的区分，却由于可以在IIS下集成.NetRemoting服务器而变得模糊，“通过在IIS中集成.NETRemoting对象，可以将其作为一种Web服务

提供……”

Remoting，简而言之，我们可以将其看作是一种分布式处理方式。从微软的产品角度来

看，可以说Remoting就是DCOM的一种升级，它改善了很多功能，并极好的融合到.Net平台下。Microsoft?.NETRemoting提供了一种允许对象通过应用程序域与另一对象进行交互的框架。这也正是我们使用Remoting的原因。为什么呢？在Windows操作系统中，是将应用程序分离为单独的进程。这个进程形成了应用程序代码和数据周围的一道边界。如果不采用进程间通信（RPC）机制，则在一个进程中执行的代码就不能访问另一进程。这是一种操作系统对应用程序的保护机制。然而在某些情况下，我们需要跨过应用程序域，与

另外的应用程序域进行通信，即穿越边界。其主机与客户端的主要任务如下：

主机任务

·设计服务，选择应用程序域、激活模式、通道、端口和发布。

·实现Remoting主机应用程序域（例如IIS/系统服务）。

·配置主机激活、通道和协议设置。建议使用配置文件，可以通过调用RemotingConfiguration.Configure加载。

·发布接口，供客户端使用（有关详细信息，请参阅下文中的“接口发布选择”）。

客户端任务

·考虑是否需要注册通道和端口。

·实现客户端应用程序域。

·配置客户端激活模式和其他类型的信息，如应用程序名称、通道和对象URI等。建议使

用配置文件，可以通过调用RemotingConfiguration.Configure加载。

用配置文件，可以通过调用

2Remoting解决方案的过程中可能会遇到的错误情况

在任何情况下，都应该记住要使用标准的设备使用和监视方法。事件记录仍是非常有价值的信息资源，就象网络监视器工具一样，网络监视器可以专门用于详细查看客户端/服务器的Remoting会话。中间层的Remoting服务器仍可以使用VisualStudio.NET提供的标准调试工具进行调试，例如，对于由IIS集成的Remoting服务器，可以通过向ASP.NET辅助进程附加调试会话（VisualStudio.Net|Debug[调试]|Processes[进程]|Attach[附加]）来设置断点（如果资源可用）。但Remoting的错误很独特，下面列出了一些。请注意，所有错误都已使用.NETFrameworkSDK提供的BasicRemotingHelloSample的各版本进行了复现，服务器和客户端也已在单机上运行。故障现象与在网络链接上的相同，只是由于HTTP/TCP的超时设置不同，需要相当长的时间才能出现错误。

2.1丢失MarshalByRef

由于Remoting要通过引用以用于给定的类，该类必须只做一件事，就是继承MarshalByRefObject。假设开发人员忘记做这项工作，我们将得到一个

System.Runtime.Remoting.RemotingException类型的异常，说明我们有一个“丢失的

MarshalByReference”.

是否能正确捕获和处理这个RemotingException将取决于程序员。（想想这个开发人员忘

记了他应记住的唯一一件事。）

解决方法是：记住继承MarshalByRefObject！

2.2众所周知的服务器激活的错误服务器端点

对于服务器激活，Remoting服务器将其侦听处声明为端点。该端点一般包括一个对象URI（远程对象的众所周知名称），一个协议和一个端口号。当然，所有这些都可能配置错

误。

2.3错误的URI

由服务提供的BasicRemotingHelloSample的URI是HelloService.soap，如相关的web.config文件中所指定：

configurat