投影同时进行的数据库查询

Question

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

我知道这里有大量变量，但我对其他人如何获得粗略数量级的感觉很感兴趣。这只是在创建任何特定设计之前的项目生命周期早期的成本计算练习，因此在此阶段没有太多信息可继续。

我从基础架构人员那里提出的问题是“同时有多少用户”。让我们不要争论只寻找这一个数字的理由；这正是本案所要求的！

这是一个 Web 前端、SQL Server 后端，具有相当固定且易于量化的受众。为了以一种非常粗略的方式将其确定为实际的同时请求，在我看来，它归结为越来越细化的度量单位：

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

这不考虑 Web 应用程序缓存、部分页面请求、记录量等因素，并且需要一些创意许可来定义每个用户的请求频率、数据库命中数和执行时间，但这似乎是合理的初始点。我也意识到需要针对峰值负载进行扩展，但如果需要，可以将其插入同步会话中。

这无疑是非常基本的，我相信那里有更全面的指导。如果有人可以分享他们对这个练习的方法，或者向我指出其他可能使该过程不那么临时性的资源，那就太好了！

Answer 1

我会尝试，但显然在不了解细节的情况下很难给出准确的建议。

首先，基础架构人员可能从许可的角度提出了这个问题（SQL Server 可以按用户或按 CPU 获得许可）

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

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

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

说了这么多 - 出于成本计算的目的，您需要着眼于更大的图景。

1. SQL 服务器许可证（如果我没记错的话）将花费约 128K 澳元（双 Xeon）。热/暖待机？成本翻倍。

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