投影同步数据库查询

时间:2010-08-17 09:28:42

标签: asp.net sql sql-server capacity-planning

我正在考虑人们如何计算数据库负载以进行容量规划。我没有把它放在服务器故障上,因为这个问题与仅测量应用程序而不是定义基础结构有关。在这种情况下,担心这一点是别人的工作!

我知道这里有大量的变量,但我对其他人如何获得粗略的数量感兴趣。在创建任何特定设计之前,这只是项目生命周期早期的成本计算练习,因此在此阶段不会进行大量信息。

我从基础设施人员提出的问题是“有多少同时用户”。我们不要辩论只寻求这一个数字的理由;这就是本案所要求的内容!

这是一个Web前端,SQL Server后端具有相当固定,易于量化的受众。为了将这个问题以非常粗略的方式确定为实际的同步请求,我看待它的方式,它归结为越来越精细的测量单位:

  1. 观众总数
  2. 同步会议
  3. 同时提出要求
  4. 同步数据库查询
  5. 这不考虑Web应用程序缓存,部分页面请求,记录量等因素,并且需要一些创造性许可证来定义每个用户的请求频率以及数据库命中数和执行时间,但这似乎是合理的初始点。我也意识到需要针对峰值负载进行扩展,但如果需要,还可以插入同步会话中。

    这是非常基本的,我相信那里有更全面的指导。如果有人可以分享他们对这个练习的方法,或者指出我可能会使这个过程不那么特别的其他资源,那就太棒了!

1 个答案:

答案 0 :(得分:0)

我会尝试,但显然不知道细节,很难给出一个精确的建议。

首先,基础设施人员可能从许可角度提出了这个问题(SQL服务器可以按用户或每个CPU获得许可)

现在回到你的问题。如果您可以预测/计算出这个数字,那么“总观众”非常重要。当所有用户同时访问数据库时(例如,每个人都登录时间为上午9点),这可以为您提供最糟糕的情况。

如果存储会话信息,则每个用户可能至少有2个连接(1个会话+ 1个主数据库)。但是这个数字可以(有时明显地)通过连接池减少(取决于你如何连接到数据库)。 使用最坏的情况 - 50个系统连接+ 2个用户数。

同时请求/查询取决于应用程序的性质。需要更多细节。 更多同时请求(到您的前端)不一定会转化为后端的更多请求。

说完所有这些 - 出于成本考虑的目的,你需要关注更大的图景。

  1. SQL服务器许可证(如果我的记忆服务对我)将花费~128K澳元(双Xeon)。热/暖待机?费用加倍。

  2. 磁盘存储 - 您需要多少存储空间?磁盘相对便宜但如果您打算使用SAN,成本可能会变得明显。此外 - 从性能角度看,磁盘越多越好。