使用SqlDependency与定期轮询表(性能影响)

本文关键字:性能 影响 SqlDependency 使用 | 更新日期: 2023-09-27 17:50:53

在我们的应用程序开发之初,我们大量使用SqlDependency来缓存DB结果,直到通知告诉我们的应用程序抓取一个新的副本。

在测试期间,我们注意到SQL DB的性能受到SqlDependency通知服务的影响。我们减少了使用SqlDependency的表的数量,并注意到性能有了很大的提高。所以,我们认为我们只是过度使用它,我们继续前进。现在只剩下几张桌子了。

后来,我们发现我们不能缩减将建立依赖的用户名的安全访问级别。我们可以为每个DB拥有多个连接字符串(一个用于依赖关系,一个用于应用程序的其余部分),但是对于多个DB和DB镜像,这是一个痛苦(从SQL数据库管理的角度和应用程序开发)。

在这一点上,我们只是考虑根据以下逻辑完全摆脱SqlDependency:
  1. 我们不需要"即时"通知数据已经更改。如果我们在1秒内知道,那就足够快了。
  2. 通过一些轻微的重构,我们可以把它减少到只有一个表,并且每秒轮询该表一次。

有人看出这个逻辑中的缺陷吗?

一次轮询一个表是否会比SqlDependency在DB上造成更多或更少的负载?

是否有人有类似的性能问题与SqlDependency?

使用SqlDependency与定期轮询表(性能影响)

我敢回答你的问题。但我不确定你会得到你所希望的答案……

我记得早在90年代早期,Borland在他们的数据库Interbase中推广了"回调"这个伟大的新特性,它会给调用者(Delphi)"通知"通过一些非常漂亮的新技术,承诺数据库可以是"活跃的"。

这后来被称为"浪费时间理论"。

我猜这从来没有发生的原因可能是,虽然DBMS的概念看起来很有前途,但数据库是你只能向上扩展而不能横向扩展的层之一。

所以编程语言来拯救。或者更确切地说是面向服务的体系结构(SOA)的思想。许多人将SOA与"web服务"混淆,这实际上是这个新概念中包含的一种炒作。

但是如果你检查一下封地/使者设计模式(或者改名为主/代理模式,使它听起来更酷更专业),你会发现其主要思想是独占控制其资源(读数据库),并且所有调用都通过一个数据适配器进行传输。

显然,这样的设计根本不适用于触发器或任何回调框架。

但是我认为你应该重新考虑你的整个设计。如果你通过一个单一的"数据层"汇集所有的动作和所有的调用,也许使用实体框架,也许在那上面有一个缓存机制,你就不必依赖你的数据库来转发消息备份食物链。

为了展示当以数据库为中心时,事情会变得多么奇怪,这里有一个极端的实际例子,关于如何不发送电子邮件,这是很久很久以前写的,由一个我不太喜欢的程序员写的:

事实1:Sql Server可以发送邮件

事实2:Asp3编码器不知道这是否或如何在VbScript中完成。

Asp3:读取文本框邮箱地址,发送到com+层

Com+:取email-address并转发到datallayer

数据层:接收电子邮件地址并转发到存储过程

Sproc:获取email地址并转发给sql函数

功能:做一些奇怪的子字符串来检查电子邮件地址是否有@。在里面。返回真或假

Sproc:返回一个记录集,其中一列和一行包含1或0

Datalayer:按原样返回表。

Com+:将值为1或0的第一列和第一行转换为真或假

Asp3:如果为true,将带有邮件主题和邮件文本的电子邮件地址发送到com+

Com+:发送准确的信息给datallayer

Datalayer:调用存储过程。

Sproc:调用sql函数…

函数:使用SQL server邮件代理发送邮件

如果你读到这里,我的建议是让sql server管理表、关系、索引和事务。它在这方面非常擅长。除了这些任务之外,我还在存储过程中包含游标,这些任务最好通过适当的代码来处理。