NET Remoting Server 性能分析及利用Loadrunner进行性能测试的方案

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

1概述

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

Web 服务提供……” -e=;X!oe{

b !=F.|Q

9k

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

L\ ip'af\\JJ ,

Mi,dyZ5

主机任务

=

· 设计服务，选择应用程序域、激活模式、通道、端口和发布。 · 实现 Remoting 主机应用程序域（例如 IIS/系统服务）。 · 配置主机激活、通道和协议设置。建议使用配置文件，可以通过调用 RemotingConfiguration.Configure 加载。 · 发布接口，供客户端使用（有关详细信息，请参阅下文中的“接口发布选择”）。

客户端任务 · 设计客户端，选择应用程序域和激活模式。 · 考虑是否需要注册通道和端口。 · 获取远程类型元数据。 · 实现客户端应用程序域。 · 配置客户端激活模式和其他类型的信息，如应用程序名称、通道和对象 URI 等。建议使用配置文件，可以通过调用 RemotingConfiguration.Configure 加载。

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

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

Km)\$5|

\\6#&\\N&k

C>%dNTEwd

y&+4FC9U-d

T\\Y+`BUHD

0S^[[gnQX>qkN\

~y= /5rXK

5AL/@Xix,| h/-;D>Cd

hhV{!

*

E%li~6?0/6/3

ot YhK^?+

\\7ZOGM NqM?m

9 *v![1r^di-|>6U

yb*~!?dA Hbt-?\\m

W&)gi'

TgR

2.1丢失 MarshalByRef

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

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

<

RS,L

MarshalByReference”. J.`I*:nj':

^LCu

是否能正确捕获和处理这个 RemotingException 将取决于程序员。（想想这个开发人员忘记了他应记住的唯一一件事。） $l:t3-GeW

)Ng&,W$_[

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

Dw

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

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

2.3错误的 URI

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

3DcaIOT}vVs :3#a;~ >u

A[Wll`ny

;b+~Mp

^,kwU5

\MF;~/z\\m2I{

>

U;

;4f]AUn^8

w?gHSu{U?c

HY-0

&Jzw

`U?7Y

C]

FVYT

5,

to

objectUri=\

o - nmLObv427

j`h{H'O0 =U[Zz^X+5!

ys0m

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

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

2.4不匹配的协议/端口

/V8 F'f UD\\m

fU5e/~Z$

\\//1R.Q

sn

XQhDWq z|

`E9?

^-q

,GOJ

k\A!*|.}f n)(

ka`H

q!bz

5x.u1

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

J>%

ak^

=Zg

h#E

u@Xo

%^\8]gf7

uA

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

pW

&

7 2|\gSq

2~`ssYy!#s

s@I??5ysgJ

nA

c^7~

?!(

!tVotJ

2-+ nU+

Mn;3

url=\http://localhost/RemotingHello/HelloService.soap\

!z&

7

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

3 Remoting 的特点 3.1 优点

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

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

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

3.2 缺点

这种三层设计的缺点与使用 XML Web service 的三层设计的缺点相同。

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

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

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

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

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

RC{ _b-;< 5\

!4;9G2KQ

Ps0uGTjT

.IdfiY

nALTv`tZs

a[K{$'P#

9

-o -bL

2L@}mJ@_o

zo_^BY,

73;xC?zin$K\\EQ4

fW:3udU_224rz0 $s&]'**>A]

&zoQ9 6-4a4{,{

l?/n2|?

CKyfZJ

k^Hjin

aZ{Kv;?C\\h$I[#j'

B;oJV)-m^

+IRPX@H_

4uoWH!zQ+T

A&-y

b <9--v

4 调试小技巧

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

9dZhH0A3!

%,Q\>w-Xx

X

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

?'Xv

$KKV\M

Q4<

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

WT

5zr

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

public enum InvokeMode

XxAo| Hy$:t8usu7[sGS.%z

~\\iXr3@\\

?+

T]

Dl \\Lw

{Local=0,Remoting}

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

P

>(|&w$-o

Bn

irQUq

,qz

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

I|

MWZ ,S?1|7onW

]g5v

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

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

6 测试工具和策略 6.1 工具简介

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

u}I}

=n$CR ?PQ

>D=.8q hC

snMRZ$h1*

8>MC

TZ >'

J!s=d` k

8 eP |

#

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

kUm$L

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

;;r0} 38tFil

7 LR计数器简介

8w8

Memory:

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

Available Mbytes:

可用物理内存数. 如果Available Mbytes的值很小（4 MB 或更小），则说明计算机上总的内存可能不足，或某程序没有释放内存。

page/sec:

p|

QEK AK

dixnn0&S@ d

ELgHH

7qs

TKBC?06,}

kv6Y[Ot:

vDn0RN%w

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

page read/sec:

3Q

]U?c* k;W(y

?O

mSLzUg

z(y

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

Kv{jG+

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

Physical Disk % Disk Time 、Physical Disk Avg.Disk Queue Length 例如，包括 Page Reads/sec 和 % Disk Time 及 Avg.Disk Queue Length。如果页面读取操作速率很低，同时 % Disk Time 和 Avg.Disk Queue Length的值很高，则可能有磁盘瓶径。但是，如果队列长度增加的同时页面读取速率并未降低，则内存不足。

要 确定过多的页交换对磁盘活动的影响，请将 Physical Disk Avg.Disk sec/Transfer 和

Memory Pages/sec 计数器的值增大数倍。如果这些计数器的计数结果超过了 0.1，那么页交换将花费百分之十以上的磁盘访问时间。如果长时间发生这种情况，那么您可能需要更多的内存。

_2U (T1WK-e'Y

IAp7,5y

RPQEjk@}+

nphAnVOb

}^yu^rTY

6By?

Page Faults/sec:

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

}Qxo:t0d

My o?}hcV

1R87

Cache Bytes：

sv{=44\

99W7=8@i

S

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

f/7.H

Wlo%QlZn

6TNw

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

<

\\4^

如 果您怀疑有内存泄露，请监视 Memory Available Bytes 和 Memory Committed Bytes，以观察内存行为，并监视您认为可能在泄露内存的进程的 ProcessPrivate Bytes、

ProcessWorking Set 和ProcessHandle Count。如果您怀疑是内核模式进程导致了泄露，则还应该监视 MemoryPool Nonpaged Bytes、Memory Pool Nonpaged Allocs 和 Process(process_name) Pool Nonpaged Bytes。

-L :faf/@UEfQ

Xr)fbL1

本文来源：https://www.bwwdw.com/article/irm5.html