从 SQL CLR 调用 Web 服务时的潜在性能问题答案

【问题标题】：Potential performance issues when calling web service from SQL CLR从 SQL CLR 调用 Web 服务时的潜在性能问题
【发布时间】：2013-01-24 08:58:59
【问题描述】：

我需要针对我的应用程序中的某些事件调用外部 Web 服务。我不想修改我的应用程序并对该外部 Web 服务建立任何依赖关系。所以，我需要想办法用某种外部组件来做到这一点。

一种可能的方法是创建数据库视图，当我的应用程序中发生某些事件时，该视图将被填满。然后我将在该视图上设置触发器，该触发器将调用 CLR 函数。在该 CLR 函数中，我将调用外部 Web 服务。通过这样做，我将获得很好的“实时”集成。但是，这种方法有缺点。主要问题是从 CLR 调用 Web 服务似乎不是一个好主意，因为它会阻塞主 SQL 线程（？！），直到 CLR 收到一些答案。

到目前为止，我只发现设置此属性将有助于解决性能问题：

System.Net.ServicePointManager.DefaultConnectionLimit = 9999

更多信息您可以找到here。

现在，既然您知道我的需求（即实时或至少接近实时的集成，而无需从我的应用程序调用外部 Web 服务），是否有更好的方法来做到这一点？

我能想到的另一种方法是使用一些服务来定期检查我的数据库中需要触发对外部 Web 服务的调用的更改。一旦此服务检测到此类更改，它将调用 Web 服务并传输数据。这当然不是真正的实时集成。我必须承认，除了性能问题，我更喜欢触发器和 CLR，因为它保证了实时集成并且对我的应用程序没有任何影响。

【问题讨论】：

不要根据触发器从 CLR 调用 Web 服务。这是个坏主意，而且会失败。而是使用排队机制。这可能是一个填满队列表的数据库触发器，以及一个通过队列表工作并调用 Web 服务的单独的外部服务或进程。如果您将触发器紧密绑定到 SQL CLR，您将遇到大问题。

标签： c# .net sqlclr

【解决方案1】：

我不确定我是否同意将 Web 服务调用移至数据库的设计。但是，我确信您不想更改应用程序是有原因的。

您可以尝试以下几个选项 -

1) 使用消息队列代替数据库和 CLR 进行 Web 服务调用。 NServiceBus 是将事件发生作为消息传递的不错选择，可以触发此调用

2) 如果您不习惯使用 SQL Server 存储事件，请查看SQL server Service broker

【讨论】：

感谢您的建议，我会调查的。更改应用程序不是一种选择，因为它更像是一种产品。因此，与特定部署相关的任何细节都被制作为一些外部组件、服务或类似的东西。
不幸的是，Service Broker 已经退出，因为我只使用 SQL Express 版本。
在这种情况下，请尝试查看 Bus 选项，如果 Bus 太重，异步队列应该会有所帮助。