SQL缓存依赖的性能问题

23

我正在从事一个项目,我们考虑使用SQLCacheDependency与SQL Server 2005/2008,并且想知道这将如何影响系统的性能。

因此,我们想知道以下问题:

SQLCacheDependency对象(查询通知)的数量是否会对SQL Server的性能产生负面影响,例如在受影响表上进行插入、更新和删除操作?

例如,在SQL Server 2005/2008中,单个表上有50000个不同的查询通知会在该表上的插入和删除操作方面产生什么影响(从性能角度)?

是否有关于如何使用SQLCacheDependencies的建议?任何官方的注意事项?我们在互联网上找到了一些信息,但没有找到性能方面的信息。

如果这里有人能回答这些问题,那就太好了。


你找到任何答案了吗?我也很想知道这个答案。 - niaher
我很遗憾这个问题已经变得陈旧,但项目上的共识是采用另一种方法,所以我们实际上从未得到任何明确的结果。然而,我在下面的答案中所读到的所有内容都包含了关于这些问题的重要信息,尽管我没有任何结果来支持这种直觉,但我认为迄今为止所有的答案都是正确的,因此我不认为我能够授予许多正确的答案。 - Kjartan Þór Kjartansson
5个回答

7
SQL缓存依赖使用轮询机制时,不应对SQL服务器或应用程序服务器造成负载。
让我们看看SQL缓存依赖需要哪些步骤以及分析它们:
  1. 数据库启用了SQL缓存依赖。
  2. 一个表,比如说“员工”,启用了SQL缓存依赖。(可以是任意数量的表)
  3. Web.config已更新以启用SQL缓存依赖。
  4. 正在使用SQL缓存依赖的页面已配置。 就是这样。
内部操作:
  • 步骤1:在数据库中创建一个名为“ASPnet_sqlcachetablesforchangenotification”的表,其中将存储启用了SQL缓存依赖的“员工”表名称,并添加一些存储过程。
  • 步骤2:在“ASPnet_sqlcachetablesforchangenotification”表中插入一个“员工”表条目。还会在此“员工”表上创建插入、更新、删除触发器。
  • 步骤3:通过提供连接字符串和轮询时间来启用应用程序进行SQL缓存依赖。
每当“员工”表更改时,触发器被触发,从而更新“ASPnet_sqlcachetablesforchangenotification”表。 现在,应用程序每5000毫秒轮询一次数据库,并检查“ASPnet_sqlcachetablesforchangenotification”表中是否有任何更改。如果有,则从内存中删除相应的缓存。
缓存与数据新鲜度(最多可以延迟5秒)相结合的重大好处。轮询由后台进程处理,不应成为性能障碍。因为如上所述,这些任务的CPU需求最小化。

4

SQLCacheDependency实现为索引视图,每次修改表时,此视图的索引都会更改。因此,对同一表有很多视图(SQLCacheDependency对象)会导致性能下降。但是,如果每个表只有1个视图(SQLCacheDependency对象),则不应该存在问题。

缓存更改通知是异步的,并在服务器有资源时触发。


由于该项目涉及到对可能会破坏您提出的“最佳实践”的表进行多个同时连接,我倾向于相信您对此进行的评估是正确的。 - Kjartan Þór Kjartansson

2

您说得对,这方面的信息确实不多,但是在这个页面中有一个与您问题相关的短语 http://msdn.microsoft.com/en-us/library/ms178604%28VS.80%29.aspx

"与SQL缓存依赖相关的数据库操作很简单,因此不会给服务器带来过重的处理负担."

希望这能对您有所帮助,尽管您的问题已经有些老了。


1

这个页面似乎有一些关于设置哪种技术使用得好的好信息(尽管我只是粗略地浏览了一下)。


2
是的,这些是设置缓存依赖项的说明,但这不是问题所在。问题是当缓存请求很多时,SQL操作的性能惩罚。不幸的是,这篇文章完全没有关于这方面的信息。 :-( - Kjartan Þór Kjartansson

1

我所能提供的只是关于性能的轶事证据,但我们将SqlCacheDependency用作大型企业应用程序的一种“消息传递解决方案”,每小时处理数万个消息。

基本架构是我们公司使用Perforce进行源代码控制,我们有一个“订阅服务”接收来自触发器Web服务调用的消息,该服务在每次p4提交时被调用,并将记录插入SQL数据库。我们的应用程序已设置依赖关系,以便对您正在监视的分支或路径影响的每个更改列表发送订阅通知。

性能很好。触发器运行时间约为200ms,我们从未收到有关中继消息到最终用户的延迟的投诉。

与往常一样,结果可能因情况而异。


网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接