的Service Broker外部激活响应多久

我的SQL Server 2014 SourceDB和LogDB对两个数据库。在SourceDB上，Service Broker;并在服务器上，Service Broker External Activator服务被激活。的Service Broker外部激活响应多久

在SOURCEDB我有TargetQueue其中一个表的（产品）的INSERT触发器将在TargetQueue变化和TargetQueue具有轻推我的外部EXE客户端事件通知。在EXE内部客户端，我最终通过WAITFOR(RECEIVE TOP (1))..将数据出队并将它们直接记录到LogDB。因此，当我启动SBEA服务并首次插入表中某个记录（删除所有记录后）时，TargetQueue立即填充，但插入到SourceDB的时间间隔直到插入到LogDB为止约为3-6秒，事件通知的时间消耗在这里我猜，我不确定。对于此后的进一步插入，间隔变为100ms，如下所示。

首先

进一步

为什么是第一个插入花费太长时间，为什么删除表中的所有记录后，就变成再走多久？为什么更多的人比第一个人短？
我可以减少10ms以下的时间间隔，因为我可以在10ms内实现与SQLCLR几乎相同的结构，最快的响应对我的应用程序也至关重要？（两个结构在同一个SQL Server实例本地工作）

来源

2017-06-14 ibubi

Service Broker的本质上是异步的。如果你想使用它作为一个技术，你应该在设计你的应用程序时考虑到这一点，也就是说，任何产生的消息最终都会被你的进程占用，但是你所描述的内容听起来很像你期望的接近队列中的同步行为。最终会失望 –

@BenThul我使用的是Service Broker，因为它是异步的，因为我的服务器会遇到很高的请求频率，为了不中断这些请求的处理或停留在其中之一，我已经使用Service Broker而不是任何同步结构（因为我最近在这里给出了很好的建议）。但如果真的如此，我真的对这个表现感到失望，所以这就是我所要求的。 – ibubi

您可以通过放弃外部激活器和事件通知来简化流程。相反，让你的程序持续运行WAITFOR（直接在目标队列接收一个循环

下面是一个样本，让你开始：。https://code.msdn.microsoft.com/Service-Broker-Message-e81c4316

来源

2017-06-14 14:27:36

这是否意味着我不应该依赖基于事件的结构来快速响应？并且，轮询Waitfor（..'语句对于sql服务器代价高昂？ – ibubi

事件通知，外部激活器本身以及它必须启动外部进程的事实都会增加时间，并且使用WAITFOR轮询（接收并不昂贵，只要你使用一个合理的超时（至少几秒钟）。 –

谢谢大卫，我会给一个尝试这种并取回的结果。 – ibubi

的Service Broker外部激活响应多久

回答

相关问题