Sql server Service Broker外部激活器响应需要很长时间

我在SQL Server 2014上有两个数据库，SourceDB和LogDB。在SourceDB上，服务代理；在服务器上，ServiceBroker外部激活器服务被激活

在SourceDB上，我有一个TargetQueue，其中一个表的Product insert触发器在TargetQueue上发送更改，TargetQueue有一个事件通知，它推动我的外部exe客户端。在exe客户端内，我最终通过WAITFORRECEIVE TOP 1.将数据出列。。并将它们直接记录到LogDB

因此，当我启动SBEA服务并在删除所有记录后第一次插入表a/几条记录时，TargetQueue立即填充，但从插入到SourceDB的时间到插入到LogDB的时间间隔约为3-6秒，我猜这是基于事件通知的时间消耗，不确定。对于此后的进一步插入，间隔变为100ms，如下所示

首先

进一步

为什么第一次插入花费的时间太长，为什么删除表中的所有记录后，又会花费很长时间？为什么，更多的要比第一个短？ 我是否可以将间隔缩短到10ms以下，因为我可以在10ms以下实现与SQLCLR几乎相同的结构，并且最快的响应对我的应用程序也至关重要？这两种结构位于同一个SQL Server实例上，在本地工作

---

您可以通过放弃外部激活器和事件通知来简化流程。相反，让您的程序直接在循环中的目标队列上连续运行waitforreceive

---

这里有一个示例可以帮助您入门：

这是否意味着我不应该依赖基于事件的结构来快速响应？然后，投票等待。。对sql server来说代价高昂的语句？事件通知、外部激活器本身以及它必须启动外部进程的事实都会增加时间。使用WAITFOR RECEIVE进行轮询并不昂贵，只要您至少使用几秒钟的合理超时时间。谢谢David，我会尝试一下，然后返回结果。David，请检查您提供的存储库的Q/a。我在Q/a中回答。Service Broker本质上是异步的。如果您想将其作为一种技术使用，那么在设计应用程序时应该考虑到这一点。也就是说，生成的任何消息最终都将被您的进程使用。但您所描述的内容听起来非常像您期望队列中出现的近乎同步的行为。您最终会失望的。@BenThul我正在使用Service Broker，因为它是异步的，因为我的服务器将遇到高频率的请求。为了不中断对这些请求的处理或停留在其中一个请求中，我使用了ServiceBroker而不是任何同步结构，因为我最近在这里给出了很好的建议。但我真的对这场演出感到失望，如果真的是这样的话，那么这就是我要问的。