投影同步数据库查询

Question

我想了解人们如何计算数据库负载以用于容量规划。我没有把它放在服务器故障上，因为这个问题与测量应用程序而不是定义基础设施有关。在这种情况下，担心这个问题是别人的工作！

我知道有一个巨大的变量数在这里，但我感兴趣的是别人如何去获得数量级的粗糙秩序感。在创建任何特定设计之前，这只是项目生命周期早期的成本计算练习，因此在此阶段没有大量信息要继续。

我从基础设施人员提出的问题是“同时有多少用户”。我们不要辩论只寻求这一个数字的理由;这正是在这种情况下所要求的！

这是一个web前端，SQL Server和一个相当固定的，容易量化的观众后端。钉下来到一个非常粗略的方式实际的并发请求，我看到它的方式，把它归结为测量的越来越精细单位：

1. 总观众
2. 并发会话
3. 同时请求
4. 同时DB查询

此不考虑因素，如Web应用程序缓存，局部页面请求，记录容量等，并有以DEFI需要一些创意牌每个用户的请求频率以及数据库命中和执行时间的数量，但这似乎是一个合理的起点。我也意识到需要调整峰值负载，但如果需要，这可以插入同时进行的会话中。

这是无可否认的非常基本，我敢肯定，那里有更全面的指导。如果任何人都可以分享他们对这个练习的方法，或者将我指向其他资源，这可能会使这个过程变得更加特别，那会很棒！

Answer 1

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

首先，基础设施球员可能会要求从许可的观点来看这个问题（SQL服务器可以按用户或CPU许可）

现在回到你的问题。如果你能预测/计算出这个数字，那么“总观众数”就很重要。当所有用户同时访问数据库时（例如，每个人登录时上午9点），这可能会导致最糟糕的情况。

如果您存储会话信息，你可能会为每位用户设置（1个会话+ 1主DB）至少2个连接。但是这个数字可以（有时候明显地）被连接池减少（取决于你如何连接到数据库）。 使用最坏的情况 - 50个系统连接+ 2 *个用户数量。

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

说了这么多 - 为了成本目的，您需要关注更大的图片。

1. SQL服务器许可证（如果我的记忆服务我的话）将花费约128K AUD（双Xeon）。热/热备用？成本加倍。

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