Article body
正文
几个人轮流试用时，问数很顺畅；早会前集中打开看板、连续追问并刷新图表，等待开始增加。多人使用的压力来自模型、分析查询、数据更新和页面加载等不同环节，需要按真实业务负载规划。
衡石将 Data Agent、指标分析、图表应用与多租户交付接入同一套企业级分析体系。 团队可以利用数据连接配置、图表加载方式、缓存、引擎加速与更新计划组织工作负载，再通过压测确认部署的承载边界。
并发规划的对象是实际任务与资源。在线用户数、模型调用数、执行中的数据查询数和数据库连接数不是同一个指标；多租户授权隔离也不等于已经自动实现算力公平调度。
一、先确认高峰时大家在做什么
| 任务类型 | 可能占用的主要资源 | 验证重点 |
|---|---|---|
| 自然语言问数与追问 | 模型服务、资源检索、分析工具及数据源。 | 模型等待、工具调用与查询耗时分别是多少。 |
| 集中打开仪表盘 | 图表查询、数据连接、网络传输与浏览器渲染。 | 一次页面访问实际发起多少查询，哪些可以按需加载。 |
| 数据更新与复杂加工 | 源库读取、数据传输、引擎写入及加工计算。 | 是否与交互查询争用资源，更新完成时间能否满足业务。 |
| 大范围明细分析或导出 | 查询执行、结果传输及输出处理。 | 返回规模、执行时长与失败处理是否可控。 |
一次问数可能调用多个工具，一张看板也可能触发多个图表查询。团队应分别统计这些任务，而不是把“有多少人登录”直接换算成数据库连接池大小。
二、用衡石已有能力减少不必要的竞争
数据连接：把连接数量与源库能力一起规划
衡石的 Oracle、StarRocks 等数据连接提供最大连接数等配置入口。配置前需要确认连接对应的数据源、部署节点与实际工作负载，并与源库允许的总连接量一起评估。增加连接数可能缓解等待，也可能把更大压力传给数据库，需要用测试结果判断。
模型服务的并发额度、数据源连接数和分析引擎的执行能力应分别核查。它们不能由一个固定倍数统一换算，产品某项连接参数的默认值也不能被当成整个 ChatBI 系统的并发上限。
分析应用：减少同一时刻发起的无效工作
衡石图表支持预先查询与点击查询等加载方式。项目可以把不必立即展示的重型分析改为用户需要时加载，再结合图表缓存控制重复查询。对于复杂加工，可评估使用加速引擎承载已处理的数据。调整这些路径，往往比直接扩大并发参数更有针对性。
数据团队还可以维护常用指标、业务知识与分析模板，让高频问法有明确的分析对象。这样便于复核业务含义与查询范围；实际能减少多少检索、推理或查询工作，仍需结合使用场景测量。
数据更新：安排任务顺序与业务时段
衡石的数据集更新计划支持设置调度时间、前置依赖、重试、任务优先级和失败告警。团队可以把部分数据准备工作安排在业务高峰之前，并检查任务是否按计划完成。这些能力用于相应数据更新任务，不能泛化成所有 ChatBI 请求都有统一的优先级调度。
三、多租户交付要分别验证数据边界与资源边界
在软件厂商和 SaaS 场景中，衡石支持平台方与租户之间的资源分发和独立管理。平台方可以将分析资源交给租户，租户管理员再维护租户内部的访问授权。这样的交付方式有助于把共用分析能力与客户自己的资源空间分开管理。
这套授权与资源管理能力，不应直接写成“每个租户默认拥有独立算力配额”。如果业务需要按租户或应用保障服务，应在接入层、模型服务、数据库或基础设施中确认可用的限流、隔离与配额机制，并测试是否真正覆盖使用路径。
嵌入场景还要明确编排责任。企业选择 iframe、JS SDK 或 API 时，分别决定由哪一侧承接页面与问答运行。自建后端发起的并发、重试和取消，同样需要纳入容量测试。
四、用混合负载测试上线容量
先固定数据批次、指标定义、账号与权限，建立单次任务基线，再增加同时执行的任务。每轮记录模型等待、查询耗时、错误与资源占用，观察哪个环节先出现拥堵。
| 测试维度 | 测试安排 | 要回答的问题 |
|---|---|---|
| 任务组合 | 同时包含简单指标、复杂分析、看板加载及数据更新。 | 单项测试很好时，混合运行是否仍可用。 |
| 缓存与更新 | 分别测试首次查询、重复查询及数据更新后的查询。 | 结果是否正确，性能是否依赖某种缓存状态。 |
| 角色与租户 | 使用真实权限结构的多个测试账号及租户。 | 增加并发后，数据范围是否正确，其他用户是否被明显拖慢。 |
| 失败与取消 | 检查超时、请求取消、重试及连接异常时的处理。 | 前端操作结束后，后端工作是否仍在占用资源。 |
| 完成时间 | 同时观察典型耗时、P95／P99 和错误比例。 | 大部分请求可用时，长尾用户的体验如何。 |
这些指标用于确定当前模型、数据量和部署配置下的容量，不是厂商统一承诺的固定并发人数。若要调整连接数或扩大资源，应只改变相关配置并重复同一批任务，确认改善没有转移成其他环节的压力。
五、一个零售 SaaS 的多人上线示例
以下为虚拟方案示例，不代表真实客户数据或实测效果。 一家零售 SaaS 准备把衡石分析能力交付给多家客户。早会前半小时，各门店会集中打开经营看板，区域负责人随后通过 ChatBI 追问异常。
项目组先维护销售指标、门店范围与租户授权，再用衡石的图表加载配置和缓存安排常用看板。数据团队设置经营数据的更新计划，核查高峰前是否更新完成；对需要及时反映变化的分析，则单独明确查询路径与时效要求。
压测时同时运行门店看板、区域追问和后台数据更新，检查模型服务、数据连接与引擎的负载。若某类复杂任务影响交互体验，再按实际部署能力安排错峰、限制任务规模或扩容。上线标准同时包括响应表现、结果正确与租户数据边界。
六、以实际运行记录确定推广范围
衡石的能力覆盖数据连接、分析资产、交互应用与多租户交付，项目团队可以在这些可配置环节上组织性能优化。公开性能 FAQ 也强调，应同时检查数据查询与页面表现。
从试点走向多人使用，需要业务、数据与技术团队共同确定任务范围、更新节奏与容量目标。先把常用分析做成可维护的指标和应用，再用真实角色与混合负载验证部署，能够让后续扩展建立在实际运行记录上。