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

.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文献中所指定：

<configuration>

<system.runtime.remoting>

<application>

<service>

<wellknownmode="SingleCall"type="Hello.HelloService,Hello"

objectUri="HelloService.soap"/>

</service>

</application>

</system.runtime.remoting>

</configuration>

此服务是IIS集成的。IIS集成规定URI带有后缀.rem或.soap，我们在服务器上使用.rope。在此实例中，我们将再次收到RemotingException，这次显示的文本是“对象</Hello.soap>在服务器上已断开或不存在”。

请保证各个URI互相匹配！当IIS集成Remoting服务器时，还要保证URI以.rem或.soap结尾。

2.4不匹配的协议/端口

为了进行此项测试，我们切换到控制台集成的服务器，以下是该服务器的配置文献：

<configuration>

<system.runtime.remoting>

<applicationname="RemotingHello">

<service>

<wellknownmode="SingleCall"type="Hello.HelloService,Hello"

objectUri="HelloService.soap"/>

</service>

<channels>

<channelref="http"port="8000"/>

</channels>

</application>

</system.runtime.remoting>

</configuration>

假设我们要在服务器端将协议更改为TCP，而使客户端保存HTTP。

我们将再次收到RemotingException，这次的文本是“底层连接已关闭：接受时出现意外错误”。

端口设立错误也会导致上述异常，唯一的不同是这种情况下，要用较长的时间才会出现错误。服务器和客户端之间的端口和协议必须匹配。

2.5丢失URI

另一种也许性是远程服务器没有运营，例如，服务器由IIS集成，而虚拟应用程序或相关的程序集丢失。再次使用BasicHelloRemoting服务器，我们需要虚拟应用程序RemotingHello可以运营。假如不能运营，我们将收到未解决的异常（取决于调用代码），但这次的异常将是：“无法加载类型clr:Hello.HelloService,Hello”。

在这些情况下，请保证虚拟应用程序在运营，并且所需的程序集对的地放置在相关的bin子文献夹中。

总而言之，客户端必须对的地引用服务器定义的端点以便激活服务器，这意味着，端口、协议和URI的定义必须互相匹配。这太容易犯错了。因此，假如服务器的位置定义为：

<service>

<wellknownmode="SingleCall"type="Hello.HelloService,Hello"

objectUri="HelloService.soap"/>

</service>

那么，客户的设立必须为：

<clienturl="http://localhost/RemotingHello">

<wellknowntype="Hello.HelloService,Hello"

url="http://localhost/RemotingHello/HelloService.soap"/>

</client>

其中，URL表达集成Remoting服务的IIS虚拟应用程序，类型表达类和程序集名称。

3Remoting的特点

3.1优点

他的优点是用户既可以使用TCP信道方式进行二进制流方式通信，也可以使用HTTP信道进行SOAP格式的性通信

效率相对WebService要高不少；但是它的缺陷也很明显，.netremoting只能应用于MS的.netframework之下。

从性能上来讲Remoting的效率和传统的DCOM、COM+的性能很相近。

3.2缺陷

这种三层设计的缺陷与使用XMLWebservice的三层设计的缺陷相同。

所有业务规则均包含在前端代码中。因而，假如需要更改业务规则，则必须更新所有客户端。除非可以进行自动更新，否则这种维护工作将十分繁琐。当然，假如使用SQLServer，则可以将某些业务规则放到存储过程中，从而减少维护的时间和成本。

所有字段名称均在源代码或控件属性中硬编码。假如更改字段名称，则必须查找和替换应用程序中所有该字段的名称。假如使用了数据绑定，还必须检查所有窗体并更改属性。

通过网络从一个组件向另一个组件传输数据比直接连接数据库要慢。在Intranet方案中，.NETRemoting的性能比XMLWebservice要好。而在Internet方案中，一般不使用.NETRemoting。

建立这种应用程序比建立两层应用程序或使用XMLWebservice的应用程序要复杂一些。

必须使用比TCP速度慢的HTTP。此外，IIS也许循环执行ASP.NET辅助进程，这将破坏所有Singleton的状态。对您来说，这也许是问题也也许不是问题，要取决于您的设计需要，由于客户端的下一个调用将重新启动Singleton。您可以将IIS配置为不循环执行辅助进程，但这种能力很有限，特别是在IIS5中，并且也许导致更进一步的影响。这里最主线的意思是，假如规定远程服务器的安全性，那么无疑要使用IIS集成。

4调试小技巧

编写Remoting程序，通常分为三部分：远程对象、服务端程序、客户端程序。假如不考虑元数据的安全性，我们会把远程对象的dll生成相同的两份，分别放到服务端和客户端。Remoting在客户端的调用是很简朴的，但调试起来就没有那么容易。由于客户端和服务器端分别属于不同的应用程序域，无法设立断点进行单步调试。假如了解NUnit，大家会知道NUnit也是不支持分布式应用程序的调试的，至少是支持得不够好。

所以，在实际做项目的过程中，我更倾向于先调用本地的对象，等调试成功后，再打开Remoting服务，调用远程对象，验证是否对的。举例来说，我要提供访问数据库的远程对象。我会先让该对象在本地运营，并调用其方法。假如一切正常，说明数据库的配置和连接均是对的的。然后再将该调用替换为远程对象。假如程序犯错，则可以肯定是Remoting提供的服务犯错了，或者是远程对象未按照Remoting的规定，没有派生MarshalByRefObject，或者未提供序列化特性。

最初使用了最愚蠢的办法，就是写两行调用，一个调用本地对象，一个调用远程对象。然后根据实际的情况，酌情考虑注释某一行代码。如此这般用了一段时间，终于觉得麻烦，迫使改变方法了。其实很简朴，就是为客户端程序的主类中，多写一个构造函数而已，呵呵：）

例如，远程对象是一个访问数据库的Remoting服务，派生MarshalByRefObject的主类名为DBAccessService。那么我一方面定义一个枚举，分别标明是属于本地调用还是远程调用：

publicenumInvokeMode

{Local=0,Remoting}

对于客户端程序，假如主类为DataBaseOperate，那么就需要增长一个构造函数和远程对象字段：

publicDataBaseOperate(InvokeModeinvokeMode)

{

switch(invokeMode)

{

caseInvokeMode.Local:

serviceObj=newDBAccessService();

break;

caseInvokeMode.Remoting:

serviceObj=(DBAccessService)Activator.GetObject(typeof(DBAccessService),"tcp://localhost:8080/DBAccessService");

break;

}

}

privateDBAccessServiceserviceObj=null;

如此这般，在客户端调用对象时，就可根据设立构造函数中的参数枚举值，灵活地改变客户端调用对象的方式。

其实这种办法也可以用简朴工厂模式来完毕。但是这个简朴工厂生产的产品和通常意义的工厂模式有点不同样哦，由于他们的产品其实是完全相同的。不同的仅仅是创建对象的方式而已。

publicclassSimpleFactory

{

publicstaticDBAccessServiceCreateInstance(InvokeModeinvokeMode)

{switch(invokeMode)

{

caseInvokeMode.Local:

returnnewDBAccessService();

break;

caseInvokeMode.Remoting:

return(DBAccessService)Activator.GetObject(typeof(DBAccessService),"tcp://localhost:8080/DBAccessService");

break;

}

}

}

然后再调用工厂的静态方法，来获得该对象即可。

两种方法都是一种思想：就是根据需要，选择不同的创建方式（其实前一种方法也可以看作是简朴工厂模式的一种变种）。假如只有一个要创建的对象，选前者更为方便；假如需要创建多个对象，用工厂方法提供多个静态方法，应当要灵活一些。

通过上述方法，不仅便于调试，也便于以后代码的修改。假如取消使用Remoting，只需改变参数枚举值即可，其他代码通通不用改变。这个技巧也算是设计模式的一种最简朴应用吧。

5测试方案

分布式应用程序中进程间通信的性能取决于以下因素：

用于跨远程边界的应用程序间传输信息的通道（涉及TCP和HTTP）占用的系统开销量。TCP套接字比HTTP更为有效。

Remoting分别使用BinaryFormatter和SOAPFormatter将对象序列化为二进制格式和SOAP格式。由于这些格式化程序使用反射，因而对于引用对象不久，但对于必须通过装箱或取消装箱来通过反射API传递的值类型则较慢。此外，SOAPFormatter还需要额外的系统开销以生成编码的SOAP消息。

我们使用测试基于访问客户和订单数据的普通业务方案。为使测试尽也许符合实际，数据库中包含100,000多行客户帐户。数据位于Orcale数据库中。

性能比较中使用了以下方法：

FrmInputSalesOrder方法产生PKID并触发btnConfirmOrder_Click事件。

FrmQueryCustomer方法接受CustomerId和参数以指定想要读取的客户行数目，并读取CustomerId大于传递给Web服务方法的CustomerId的前n行。

测试过程中，我们逐页提取不同类型客户行集合，然后查询商品，填写完销售订单后，提交保存。在这个过程中，用LR模拟100虚拟用户同时进行操作，检测系统响应时间及其他性能参数。

6测试工具和策略

6.1工具简介

在本测试中，我们使用了MI公司的loadrunner。它可以对Web服务器进行强度测试，分析Web应用程序（涉及ASPX页及其使用的组件）的性能和可伸缩性问题。有关如何创建和运营测试的具体信息，请参阅loadrunner使用手册。通过打开到服务器的多个连接并迅速发送HTTP请求，loadrunner可以模拟一大组用户。它还允许我们建立实际的测试方案，我们可以在方案中使用一组随机参数值调用同一个方法。此功能很重要，因为用户不也许会使用相同的参数值反复调用同一个方法。另一个有用的功能是，loadrunner可以记录测试结果，然后进行分析，从而提供有关Web应用程序性能的最重要的信息。

6.2解决Loadrunner中没有相关Remoting协议的问题

因为在C/S的ERP系统中，LR并没有remoting相关协议可以选择，直接导致了LR无法录制操作环节，取得脚本程序。解决这种状况有一种方法，即：去MERCURY官方站点去下载一个基于.NETRemoting的add-in的补丁包，把此包集成于.NETC#开发环境中，这时，开发环境上方工具条会出现一个Vuser的新控件（见下图）。我们调入被测源程序，然后在其中创建一个Loadrunner的新项目，然后根据被测对象，在开发环境中写出测试代码。最后运用Vuser项创建LR的场景，它会自动调用LR去做，设立完毕运营即可。当完毕场景运营之后，运用LR的Analysis工具进行分析即可。

7LR计数器简介

Memory:

内存使用情况也许是系统性能中最重要的因素。假如系统“页互换”频繁，说明内存局限性。“页互换”是使用称为“页面”的单位，将固定大小的代码和数据块从RAM移动到磁盘的过程，其目的是为了释放内存空间。尽管某些页互换使Windows2023可以使用比实际更多的内存，也是可以接受的，但频繁的页互换将减少系统性能。减少页互换将显著提高系统响应速度。要监视内存局限性的状况，请从以下的对象计数器开始：

AvailableMbytes:

可用物理内存数.假如AvailableMbytes的值很小（4MB或更小），则说明计算机上总的内存也许局限性，或某程序没有释放内存。

page/sec:

表明由于硬件页面错误而从磁盘取出的页面数，或由于页面错误而写入磁盘以释放工作集空间的页面数。一般假如pages/sec连续高于几百，那么您应当进一步研究页互换活动。有也许需要增长内存，以减少换页的需求（你可以把这个数字乘以4k就得到由此引起的硬盘数据流量）。Pages/sec的值很大不一定表白内存有问题，而也许是运营使用内存映射文献的程序所致。

pageread/sec:

页的硬故障，page/sec的子集，为了解析对内存的引用，必须读取页文献的次数。阈值为>5.越低越好。大数值表达磁盘读而不是缓存读。

由于过多的页互换要使用大量的硬盘空间，因此有也许将导致将页互换内存局限性与导致页互换的磁盘瓶径混淆。因此，在研究内存局限性不太明显的页互换的因素时，必须跟踪如下的磁盘使用情况计数器和内存计数器：

PhysicalDisk%DiskTime、PhysicalDiskAvg.DiskQueueLength例如，涉及PageReads/sec和%DiskTime及Avg.DiskQueueLength。假如页面读取操作速率很低，同时%DiskTime和Avg.DiskQueueLength的值很高，则也许有磁盘瓶径。但是，假如队列长度增长的同时页面读取速率并未减少，则内存局限性。

要拟定过多的页互换对磁盘活动的影响，请将PhysicalDiskAvg.Disksec/Transfer和MemoryPages/sec计数器的值增大数倍。假如这些计数器的计数结果超过了0.1，那么页互换将花费百分之十以上的磁盘访问时间。假如长时间发生这种情况，那么您也许需要更多的内存。

PageFaults/sec:

每秒软性页面失效的数目（涉及有些可以直接在内存中满足而有些需要从硬盘读取）较page/sec只表白数据不能在内存的指定工作集中立即使用。

CacheBytes：

文献系统缓存（FileSystemCache），默认情况下为50%的可用物理内存。如IIS5.0运营内存不够时，它会自动整理缓存。

需要关注该计数器的趋势变化

如果您怀疑有内存泄露，请监视MemoryAvailableBytes和MemoryCommittedBytes，以观测内存行为，并监视您认为也许在泄露内存的进程的ProcessPrivateBytes、ProcessWorkingSet和ProcessHandleCount。假如您怀疑是内核模式进程导致了泄露，则还应当监视MemoryPoolNonpagedBytes、MemoryPoolNonpagedAllocs和Process(process_name)PoolNonpagedBytes。

Pagespersecond:

每秒钟检索的页数。该数字应少于每秒一页。

Process：

%ProcessorTime:

被解决器消耗的解决器时间数量。假如服务器专用于sqlserver,可接受的最大上限是80-85%

PageFaults/sec:将进程产生的页故障与系统产生的相比较，以判断这个进程对系统页故障产生的影响。

Workset:

解决线程最近使用的内存页，反映了每一个进程使用的内存页的数量。假如服务器有足够的空闲内存，页就会被留在工作集中，当自由内存少于一个特定的阈值时，页就会被清除出工作集。

Inetinfo:PrivateBytes:

此进程所分派的无法与其它进程共享的当前字节数量。假如系统性能随着时间而减少，则此计数器可以是内存泄漏的最佳指示器。

Processor：监视“解决器”和“系统”对象计数器可以提供关于解决器使用的有价值的信息，帮助您决定是否存在瓶颈。

%ProcessorTime:

假如该值连续超过95%，表白瓶颈是CPU。可以考虑增长一个解决器或换一个更快的解决器。

%UserTime:

表达花费CPU的数据库操作，如排序，执行aggregatefunctions等。假如该值很高，可考虑增长索引，尽量使用简朴的表联接，水平分割大表格等方法来减少该值。

%PrivilegedTime：

（CPU内核时间）是在特权模式下解决线程执行代码所花时间的比例。假如该参数值和"PhysicalDisk"参数值一直很高，表白I/O有问题。可考虑更换更快的硬盘系统。此外设立TempdbinRAM，减低"maxasyncIO"，"maxlazywriterIO"等措施都会减少该值。

此外，跟踪计算机的服务器工作队列当前长度的ServerWorkQueuesQueueLength计数器会显示出解决器瓶颈。队列长度连续大于4则表达也许出现解决器拥塞。此计数器是特定期间的值，而不是一段时间的平均值。

%DPCTime:

越低越好。在多解决器系统中，假如这个值大于50%并且Processor:%ProcessorTime非常高，加入一个网卡也许会提高性能，提供的网络已经不饱和。

Process

%ProcessorTime指这个线程使用解决器执行指令的所用时间的比例。类似于Processor的%ProcessorTime

%PrivilegedTime指这台解决器的线程用于执行在特权模式中的代码所通过时间的比例。类似于Processor的%PrivilegedTime

%UserTime指这台解决的线程用于执行使用用户模式的代码的时间的比例。类似于Processor的%UserTime

PrivateBytes指这个解决不能与其它解决共享的、已分派的当前字节数。假如此数值随时间不断增大，有也许是内存泄漏。

VirtualBytes指解决使用的虚拟地址空间的以字节数显示的当前大小。使用虚拟地址空间不一定是指对磁盘或主内存页的相应的使用。虚拟空间是有限，假如使用过多，也许会限制解决加载数据库的能力。

IODataBytes/sec解决从I/O操作读取/写入字节的速度。这个计数器为所有由本解决产生的涉及文献、网络和设备I/O的活动计数。

Processor

%ProcessorTime指解决器执行非闲置线程时间的比例。这个计数器设计成用来作为解决器活动的重要指示器。它通过在每个范例间隔中衡量解决器用于执行闲置解决线程的时间，并且用100%减去该值得出。(每台解决器有一个闲置线程，该线程在没有其它线程可以运营时消耗周期)。可将其视为范例间隔用于做有用工作的比例。这个计数器显示在范例间隔时所看到的忙时平均值。这个值是用100%减去该服务不活动的时间计算出来的。

正常值<90，此值过大表达解决器的性能已经不能应付程序的规定，要换更快的解决器。

%PrivilegedTime指非闲置解决器时间用于特权模式的比例。(特权模式是为操作系统组件和操纵硬件驱动程序而设计的一种解决模式。它允许直接访问硬件和所有内存。另一种模式为用户模式，它是一种为应用程序、环境分系统和整数分系统设计的一种有限解决模式。操作系统将应用程序线程转换成特权模式以访问操作系统服务)。特权时间的%涉及为间断和DPC提供服务的时间。特权时间比率高也许是由于失败设备产生的大