与序列化相比,使用 MarshalByRefObject 的成本有多高?

发布于 2024-11-17 11:55:38 字数 1123 浏览 1 评论 0原文

在我的 Azure Web 角色代码中,我有一个派生自 System.Security.Principal.IIdentityCustomIdentity 类。在某些时候.NET运行时尝试序列化该类序列化不起作用。试图解决这个问题,我搜索了很多并找到 这个答案 并尝试从 MarshalByRefObject

现在,一旦我的 CustomIdentity 类继承了 MarshalByRefObject ,就不再进行序列化尝试,并且我的代码可以正常工作。不过,我想知道使用 MarshalByRefObject 类对性能的影响。

我的代码是这样运行的。首先,请求到达 IIS,并传递给身份验证代码,该代码创建 CustomIdentity 实例并将该实例附加到 HTTP 上下文。然后一段时间后,相同的 HTTP 上下文将传递到最多访问该 CustomIdentity 实例一次的 ASP.NET 处理程序。 CustomIdentity 对象在请求期间存在,然后被销毁。

现在,通过序列化,我的 CustomIdentity 将被序列化为一个流,然后从该流反序列化为一个新对象。使用 MarshalByRefObject 时,没有序列化,但会创建一个代理,并且将通过 RPC 将访问封送到实际对象所在的位置。

在这种情况下使用 MarshalByRefObject 的成本有多高? MarshalByRefObject 和序列化哪个成本更高?

In my Azure web role code I have a CustomIdentity class derived from System.Security.Principal.IIdentity. At some point .NET runtime tries to serialize that class and serialization wouldn't work. Trying to resolve that I searched a lot and found this answer and tried to inherit my class from MarshalByRefObject.

Now once my CustomIdentity class inherits from MarshalByRefObject there're no serialization attempts anymore and my code works. However I'd like to know the performance implications of using MarshalByRefObject class.

My code runs like this. First the request comes to IIS and is passed to the authentication code that creates an instance of CustomIdentity and attaches that instance to HTTP context. Then some time later the same HTTP context is passed to the ASP.NET handler that accesses that CustomIdentity instance at most once. The CustomIdentity object lives for the duration of request and is then destroyed.

Now with serialization my CustomIdentity would be serialized into a stream, then deserialized from that stream into a new object. With MarshalByRefObject there's no serialization but a proxy is created and the access will be marshaled via RPC to where the actual object resides.

How expensive will using MarshalByRefObject be in this scenario? Which - MarshalByRefObject or serialization - will be more costly?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

递刀给你 2024-11-24 11:55:38

MarshalByRefObject 意味着所有调用(方法、属性等)都通过线路进行代理。这可能意味着您不是传输一次数据,然后在本地对传输的数据运行多个方法等,而是每次访问都进行网络调用。例如,一个角色被测试了多少次(每个请求)?或查询的名称?老实说我不知道​​,但我猜它超过 1(全部总计)。再加上原始的设置成本......

带宽可能不会很大,但延迟非常显着,特别是如果您有分布式节点(因为您提到了云场景) )。

就我个人而言,我会像避免瘟疫一样避免 MarshalByRefObject,但取决于你......

MarshalByRefObject means that all calls (methods, properties, etc) are proxied over the wire. This potentially means that instead of transferring the data once and then running multiple methods etc locally on the transferred data, you are making a network call every access. How many times (per request) is a role tested, for example? or the name queried? I honestly don't know, but I'm guessing it is more than 1 (all totalled). Plus the original setup costs...

The bandwidth probably won't be significant, but latency is very significant, especially if you have distributed nodes (since you mention a cloud scenario).

Personally, I would avoid MarshalByRefObject like the plague, but up to you...

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文