远程处理性能随着时间的推移而下降

发布于 2024-07-09 08:51:15 字数 1784 浏览 6 评论 0原文

我正在开发一个客户端-服务器解决方案,该解决方案使用 .NET 2.0 远程处理(服务器激活、通过 TCP 通道的二进制格式化、Vista Ultimate)进行通信。 目前,我正在分析应用程序并在同一台计算机上运行所有内容。 我注意到,如果我启动应用程序,几分钟内一切都会正常工作,然后突然每个远程调用都需要几秒钟才能执行。 我在两端都登录并记录每个呼叫。 服务器端的实现只需要几分之一秒的时间即可执行,而整个远程调用速度很慢。 进一步的分析表明,远程处理在服务器端性能下降:虽然远程服务的内部工作在不到一秒的时间内执行,但响应速度非常慢。 如果我重新启动服务器,几分钟内一切都会恢复正常。

有人经历过类似的事情吗?

谢谢!

更新: 我检查过,如果我将远程对象的生命周期配置为 1 天,我仍然遇到同样的问题。

更新: 我正在使用 Ingo Ramer 建议的模式(HOWTO:使用基于接口的远程带有配置文件的对象)用于我所有的远程处理内容,如果这有什么区别的话。

客户端代码:

public static object CreateInstance(Type type)
{
    if (!Initialized)
        InitWellKnownTypesCache();

    WellKnownClientTypeEntry typeEntry = (WellKnownClientTypeEntry)wellKnownTypesCache[type];
    if (null == typeEntry)
        throw new RemotingException("Type not found.");

    if (string.IsNullOrEmpty(serverObjectActivationUri))
        throw new RemotingException("ServerObjectActivationUri wasn't configured. Cannot create server object instance.");

    return Activator.GetObject(typeEntry.ObjectType, string.Format(serverObjectActivationUri, typeEntry.ObjectUrl));
}

服务器端只有正确的配置文件,如下所示:

        <service>
            <wellknown 
                mode="Singleton" 
                type="MyDomain.SomeDomain, MyDomain" 
                objectUri="SomeDomainService"
            />

除了 RemotingConfiguration.Configure("MyDomainService.exe.config", false); 之外,我没有做任何事情 既不在我的服务器代码中,也不在客户端代码中。

I'm working on a client-server solution that uses .NET 2.0 Remoting (server activation, binary formatting over TCP channel, Vista Ultimate) for communication purposes. Currently I'm profiling the application and run everything on the same machine. I noticed that if I start the application, everything works just fine for several minutes and then suddenly each remote call takes several seconds to execute. I have logging on both ends and clock every call. Server side's implementation takes only fraction of a second to execute, while the whole remote call is slow. Further profiling showed that remoting degrades on the server side: while inner working of the remote service execute within a fraction of a second, the responses are very slow. If I restart server everything backs to normal for several minutes again.

Did anyone experience something like that?

Thanks!

UPDATE:
I checked, if I configure lifetime for my remote object to, say, 1 day, I still have the same problem.

UPDATE:
I'm using the pattern suggested by Ingo Ramer (HOWTO: Use Interface-based remote objects with config files) for all my remoting stuff, if this makes any difference.

Client code:

public static object CreateInstance(Type type)
{
    if (!Initialized)
        InitWellKnownTypesCache();

    WellKnownClientTypeEntry typeEntry = (WellKnownClientTypeEntry)wellKnownTypesCache[type];
    if (null == typeEntry)
        throw new RemotingException("Type not found.");

    if (string.IsNullOrEmpty(serverObjectActivationUri))
        throw new RemotingException("ServerObjectActivationUri wasn't configured. Cannot create server object instance.");

    return Activator.GetObject(typeEntry.ObjectType, string.Format(serverObjectActivationUri, typeEntry.ObjectUrl));
}

Server side has nothing but proper config file that looks like:

        <service>
            <wellknown 
                mode="Singleton" 
                type="MyDomain.SomeDomain, MyDomain" 
                objectUri="SomeDomainService"
            />

I don't do anything beyond RemotingConfiguration.Configure("MyDomainService.exe.config", false); neither in my server nor client code.

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

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

发布评论

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

评论(8

只是我以为 2024-07-16 08:51:15

使用Wireshark等网络监控工具来查看您的问题是否与网络相关或与服务器同步相关。

如果证明这不是网络问题,则尝试在链中附加一个简单的自定义同步(就在通道之前)以记录并获取挂钩之间的计时。

Use some network monitoring tool like Wireshark to see if your problem is network related or server sync related.

If it proves that it is not a network issue, then try to attach a simple custom sync in the chain (just before the channel) to log and get the timing between the hooks.

无人问我粥可暖 2024-07-16 08:51:15

绝不。 您是否正在做一些导致远程处理层的额外实例被注册/实例化的事情?

Never. Are you doing something that's causing extra instances of your remoting layer to be registered/instantiated??

留一抹残留的笑 2024-07-16 08:51:15

浏览一下您的代码或其子集也会有所帮助。

A glance at your code, or a subset thereof, would also help.

今天小雨转甜 2024-07-16 08:51:15

您是否与客户赞助商一起赞助您的远程对象?

Are you sponsoring your remoted objects with a client sponsor?

二智少女 2024-07-16 08:51:15

我将远程通道的类型从 tcp 更改为 http,同时保留二进制格式。 我可以在几分钟的不活动状态下看到同样的减慢,但与 tcp 通道不同,在客户端进行“缓慢”远程调用后,服务器“醒来”并且所有后续调用都很快,直到下一个不活动周期到来并且服务器又睡着了。

这不可能是一个解决方案,但至少是某种解决方法。

I changed my remoting channel's type from tcp to http, while leaving the binary formatting. I can see the same slowdown in several minutes of inactivity, but unlike the tcp channels, after the client makes a "slow" remote call, the server "wakes up" and all subsequent calls are fast, until next period of inactivity comes and server goes asleep again.

No way this is a solution, but at least some sort of workaround.

絕版丫頭 2024-07-16 08:51:15

这可能与终身租赁有关。
Singleton 对象受为其指定的生命周期租用约束,因此即使客户端当前持有对它的引用,它也可以被回收。 您可以通过重写 MarshalByRefObject 的 InitializeLifetimeService 方法来创建前一种类型的 Singleton 对象。

It could be related with lifetime lease.
A Singleton object is subject to the lifetime lease that was specified for it, so it can be recycled even if clients currently hold references to it. You can create the former type of Singleton object by overriding the InitializeLifetimeService method of MarshalByRefObject.

断肠人 2024-07-16 08:51:15

您可以尝试为您的类尝试 MTAThread 属性吗,只是一个想法..

Can you try MTAThread attribute for your class, just a thought..

潦草背影 2024-07-16 08:51:15

您是否偶然进行了大量远程调用? 如果您的调用速度足够快,则可能会耗尽线程来处理请求。

这可能不是你的问题,但我以前遇到过这个问题,所以我想我把它传递给你了。

Are you by chance making large numbers of remoting calls? If you're making the calls fast enough you could be running out of threads to handle the requests.

That's probably not your issue, but I've run into that before so I thought I pass that along.

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