代码之家  ›  专栏  ›  技术社区  ›  Troy Hunt

同时投影数据库查询

  •  2
  • Troy Hunt  · 技术社区  · 14 年前

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

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

    我从基础设施人员那里提出的问题是有多少同时使用的用户。让我们不要争论只寻求这一个数字的基本原理;它只是在这个案例中被要求的东西!

    这是一个Web前端、SQL Server后端,具有相当固定、易于量化的访问群体。为了以一种非常粗略的方式将这一点归结为实际的同时请求,在我看来,它归结为日益细化的度量单位:

    1. 总观众
    2. 同时会话
    3. 同时请求
    4. 同时数据库查询

    这并不能解释诸如Web应用缓存、部分页面请求、记录量等因素,并且需要一些创造性的许可来定义每个用户的请求频率、数据库点击数和执行时间,但这似乎是一个合理的起点。我也意识到需要为峰值负载进行缩放,但如果需要,这是可以插入同步会话的其他东西。

    诚然,这是非常基本的,我相信有更全面的指导。如果有人能分享他们的方法来做这个练习,或者把我引向其他资源,这些资源可能会使这个过程不那么特别,那就太好了!

    1 回复  |  直到 14 年前
        1
  •  0
  •   DmitryK    14 年前

    我会尽力的,但显然,在不知道细节的情况下,很难给出准确的建议。

    首先,基础架构人员可能从许可的角度提出了这个问题(SQL Server可以按用户或每CPU授予许可)。

    现在回到你的问题上来。”如果你能预测出这个数字,“总观众”是很重要的。当所有用户同时访问数据库时(例如,当所有人登录时,上午9点),这会给您带来最坏的情况。

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

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

    所有这些都说了——为了成本核算的目的,你需要着眼于更大的全局。

    1. SQL Server许可证(如果我的内存服务正常)将花费大约128K澳元(双Xeon)。热/热备用?双倍的成本。

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