高性能数据库查询

时间:2010-10-12 17:41:49

标签: .net wcf performance caching desktop-application

我有一个.NET桌面应用程序,由遍布加拿大的5000名用户使用。 其中一项功能是使用我们从数据库中获取的一些参数与某些调制解调器进行通信。

此功能的独特之处在于:

1 - 它应该非常快,因为它正在与调制解调器工具通信,并且这些调制解调器有一段时间,我们无法控制它。

2 - 我们从数据库中读取的信息非常大,它们具有所有调制解调器类型的参数,类似于2000个。

3 - 这些信息不会经常变化。 他们每月只改变一次。

处理这个问题的最佳方法是什么?

我正在考虑在应用程序启动时请求所有这些信息,并将其保存在内存中,但我对此犹豫不决,因为它可能需要一些时间,因为有大量的信息。

我们的工作标准是每当我们想要与数据库进行通信时都有WCF服务,但我可以为该规则获得例外,但与此同时,如果可能的话,坚持使用该规则是很好的。

我的问题是,我们可以在服务器端进行WCF服务缓存吗? 因此,如果一个客户端请求一个调制解调器类型的数据,它将在缓存中用于所有后续请求? 考虑到我们为WCF服务提供了多服务器,因此使用此设置缓存会更复杂。

是WCF缓存(如果可能)是最好的答案?

如果我们绕过WCF并直接访问数据库,我们能获得任何好处吗?

请建议,因为这是非常关键的问题

3 个答案:

答案 0 :(得分:1)

为什么不让所有客户拥有自己的数据副本?你声明自己并没有太频繁地改变。您可以将它放在轻量级数据库中,例如SQLite;或者在XML文件中。

然后你可以使用版本控制方案。存储版本号以及本地数据。启动应用程序时,使用Web服务向中央服务器询问最新数据的当前版本号。如果版本号不同,请下载新数据集。

这样,如果中央SQL服务器关闭(或者网络连接丢失,延迟很高等),您的应用程序也将起作用。

每当表现很关键时(例如,如果在一个时间范围内没有收到答案,事情就不起作用),我会尽量避免依赖网络。

答案 1 :(得分:0)

我会说,对于任何基于性能的应用程序,您需要查看通过线路传输的数据量并尽可能地限制它。

对于WCF,请查看实际的请求结构,并确定请求本身或请求中的数据是否是限制因素。

一些指示:远离任何看起来像XML的东西。如果可能,您必须使用JSON表示法,甚至只需一个简单的CSV记录格式。例如:“value1”,“value2”......

如果数据不经常更改,您可以将初始请求传递给它当前拥有的数据的版本号,并让服务器确定它是否具有最新版本。这可能从根本上减少您必须发送的数据量。作为旁注,这是大多数缓存系统的工作方式。

答案 2 :(得分:0)

首先,我会像往常一样写这个。我怀疑这可能根本不是一个问题 - 检查的唯一方法是实现它并分析,看看这里是否确实存在性能瓶颈。我理解想要防止调制解调器挂起,但调制解调器设备上的超时时间并不短,并且通常可配置以便延长。

  

我们从数据库中读取的信息非常大,它们具有所有调制解调器类型的参数,类似于2000个。

2000调制解调器的调制解调器参数似乎不是一个大量的信息 - 最多,我希望这是一个几兆字节的数据。如果是这种情况,请将其加载到服务器上的内存中,以便更快地使WCF服务。

话虽这么说,如果客户端知道他们将使用的调制解调器的类型,他们总是可以在首次使用之前在线路上提取这些调制解调器类型所需的信息。并非每个客户端都将与所有2000种调制解调器类型连接,因此只有少数类型需要本地。由于这种情况很少发生变化,因此甚至可以将其缓存在本地应用程序商店中,从而无需重新获取数据。