我们的应用程序中有一个每月运行一次的大型流程。此过程通常运行约 30 分钟,并生成约 342000 个日志事件。最近,我们使用 WCF 将日志记录更新为集中式模型,但现在遇到了性能问题。以前的解决方案大约需要 30 分钟即可完成,但采用新的日志记录后,现在需要 3 或 4 小时。问题似乎是因为应用程序实际上正在等待 WCF 请求完成才能继续执行。 WCF 方法已配置为 IsOneWay,我将客户端对该 WCF 方法的调用包装在不同的线程中,以尝试防止此类问题,但它似乎不起作用。我曾考虑过使用异步 WCF 调用,但在尝试其他方法之前我想我会在这里询问是否有更好的方法来处理这个问题。
30 分钟内记录了 342000 个日志事件,如果我计算正确的话,每秒会记录 190 个日志事件。我认为您的问题可能与 WCF 中的默认限制设置有关。即使您的方法设置为单向,根据您是否为每个记录的事件创建新代理,在创建代理、打开通道以及如果您使用的是基于 HTTP 的绑定,它将阻塞,直到服务接收到消息(基于 HTTP 的绑定发回null收到消息时对单向方法调用的响应)。默认的 WCF 限制将服务端的并发实例限制为 10 个,这意味着一次只会处理 10 个请求,任何进一步的请求都将排队,因此将其与 HTTP 绑定配对,前 10 个请求之后的任何请求都会被处理。将阻塞客户端,直到它成为 10 个请求之一得到处理。在不知道您的服务如何配置(实例模式等)的情况下,很难说更多,但如果您使用每次调用实例,我建议您设置MaxConcurrentCalls
and MaxConcurrentInstances
在你的ServiceBehavior
到更高的值(默认值分别为 16 和 10)。
另外,为了建立在其他人提到的关于聚合多个事件并一次提交所有事件的基础上,我发现设置静态文件很有帮助Logger.LogEvent(eventData)
方法。这样,在整个代码中使用起来就很简单,并且您可以在自己的代码中进行控制LogEvent
方法您希望日志记录在整个应用程序中的行为方式,例如配置一次应提交多少个事件。
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)