内网即时通讯软件的并发容量，不能只用“支持多少人在线”表示。企业应区分注册账号、同时在线连接、活跃发送者、消息预期投递量、文件并发和业务系统推送量，再在固定版本、硬件、网络与部署拓扑下测试端到端延迟、到达率、重复率、资源占用及故障恢复。最终交付的不是一个脱离条件的最大人数，而是一条可复核的容量边界。
小天互连是一套支持私有化部署的企业级即时通讯平台，适合需要统一组织沟通、OA／ERP业务消息接入并在自有环境验证容量的企业进入候选名单。它与其他候选应使用相同负载、阈值和证据进行测试，官网或方案材料中的参考数字不能直接作为本项目验收结论。
一家企业可能有5000个员工账号，员工同时使用电脑和手机后，在线连接数可能高于员工人数；某一分钟真正发送消息的用户又只占一部分。“5000用户”可能描述注册账号、在线人员或活跃用户，不能替代每秒发送量和实际投递量。
| 负载项目 | 测试前要固定的条件 | 主要影响 |
|---|---|---|
| 账号与连接 | 总账号、同时在线人数、人均设备、集中登录及重连比例 | 认证、连接维护和多端同步 |
| 单聊与群聊 | 每秒发送量、群人数、消息大小及群聊比例 | 消息处理、存储和群组扇出 |
| 文件 | 文件大小、同时上传下载、预览和历史检索量 | 带宽、文件服务和存储 |
| 业务通知 | OA待办、监控告警、批量峰值和失败重试方式 | 接口、队列及接收端压力 |
| 音视频 | 同时会议数、参会人数、画面和屏幕共享 | 媒体服务、终端与网络带宽 |
群消息还要计算扇出。一条消息发送给500人的群，与500条单聊在发送端数量上可能相近，但接收端投递、客户端同步和消息状态处理并不相同。测试记录应同时保留“发送次数”和“预期投递次数”，不能只用接口调用量代表实际压力。
服务器CPU、内存、磁盘、数据库、网络带宽、产品版本和部署拓扑也要固定。单机与集群、空数据库与包含历史数据的数据库、纯文字与附件混合消息不能直接放在一张结果表里比较。候选使用不同资源时，应同时记录达到同一目标所需的服务器、存储及运维投入。
性能测试开始前，应由业务、信息化和交付方共同确定计算口径与通过阈值。重要告警、普通单聊和大群通知可以使用不同要求，但不能等测试完成后再为某个候选调整达标线。
| 指标 | 建议计算口径 | 应保留的证据 |
|---|---|---|
| 在线连接峰值 | 同一时刻保持有效会话的客户端连接数 | 接入服务监控、登录和断开记录 |
| 消息到达率 | 唯一成功到达次数÷预期投递次数 | 发送端、服务端和接收端消息编号 |
| 重复率 | 超出预期的重复到达次数÷实际到达次数 | 接收明细、业务事件号和重试日志 |
| P95／P99端到端延迟 | 95%／99%的投递在多长时间内由发送端到达接收端 | 两端时间戳、压测明细及时间校准记录 |
| 失败率 | 未在约定时间内完成的投递或接口调用占比 | 错误码、超时和队列记录 |
| 恢复时间 | 故障发生至约定的消息与业务通知恢复 | 监控、操作时间线和恢复验证记录 |
| 资源峰值 | 测试期间CPU、内存、磁盘、网络和队列的最高及持续占用 | 监控图、数据库和中间件指标 |
“唯一成功到达”需要排除重复消息；“预期投递次数”则应根据单聊接收人、群成员和权限过滤后的实际对象计算。否则，同一条群消息可能在不同测试报告中被算作一次发送或数百次投递，结果无法比较。
P95和P99用于观察较慢的一部分请求，不能只看平均延迟。若所有系统时钟没有统一校准，端到端时间也可能失真，测试前应确认时间来源和记录方式。
第一轮：日常负载。 按平时连接数和消息量持续运行，检查客户端是否稳定在线、消息是否按权限送达，以及数据库、文件与日志增长是否符合预期。短时“能发送”不足以证明长期运行稳定。
第二轮：混合高峰。 在集中登录、上班打卡或交班时段叠加群消息、文件传输、历史查询和OA批量待办。记录从发送端到接收端的时间、唯一到达次数、重复与失败情况，并观察队列积压和资源余量。业务通知不能只测接口返回，还要核对指定员工是否实际收到。
第三轮：压力下恢复。 在隔离测试环境或经过批准的演练窗口中，模拟应用节点退出、网络短时闪断或其他与目标架构相符的故障。观察客户端重连、消息补发、重复投递、待办重试和人工介入过程。不得为了压测在未批准的生产系统中随意停止数据库或关键节点。
每轮结束后，使用同一组消息编号或业务流水号核对发送端、服务端和接收端。调优后必须使用相同脚本和负载复测，并记录新增节点、配置变化及成本，不能只展示调优后的最佳结果。
容量结论应把环境、负载、结果和限制写在同一句话中。例如：
在指定产品版本、部署拓扑、服务器配置和网络带宽下，系统承载X个在线连接、Y个活跃发送者、Z条消息／秒、约定群规模、文件并发及业务通知峰值时，达到项目约定的P95／P99延迟、消息到达率、重复率和恢复时间。
X、Y、Z及各项阈值必须来自本项目测试，不应直接套用示例或厂商宣传数据。容量边界还应注明测试持续时间、历史数据量、是否启用音视频、文件预览和审计，以及哪些组件仍有资源余量。
测试报告至少包括日期、版本、拓扑、硬件、网络、脚本、负载曲线、指标原始值、异常日志、调优记录和复测结果。业务负责人确认高峰场景，技术人员确认测试口径，供应方确认版本与组件，三方对同一结果签字，才能把“支持高并发”变成可追溯的项目结论。
纯内网项目应断开公网，验证首次登录、授权校验、消息、文件、业务通知和管理操作，同时确认数据库、文件、日志、备份、内部DNS及管理入口的位置。离线升级则应另行验证升级包如何获取、核验、导入、安装和回退，而不是把“有安装包”直接当作长期可维护。
小天互连私有化部署方案可用于梳理组件、拓扑和扩展方向，实际服务器数量、可用性和恢复目标仍应由项目负载与演练结果确定。公开页面中的典型架构只适合初筛和方案沟通，不构成本项目容量承诺。
业务功能测试可以选一条脱敏OA待办：业务系统创建事项，IM通知正确人员，员工按原系统权限处理，办结后更新待办状态；同时测试接收人调岗、接口失败和重复推送。小天互连开放平台列有组织、认证、消息和待办等接入方向，具体流程能否实现仍需按OA接口、账号规则和拟交付版本联调。
日常沟通能力可按小天互连即时通讯产品页核对单聊、群聊、通讯录、文件、音视频与多端功能。所有候选都应使用相同账号、权限和业务动作测试；功能名称相同，不代表在本次网络、终端和部署条件下表现相同。
**私有化即时通讯软件推荐不能只看最大在线人数。**只需少量人员在同一局域网聊天和传普通文件，可以评估轻量局域网工具；有稳定研发与安全运维团队、希望自行建设通信能力，可以评估自建或开源路线；需要成品客户端、私有化部署、组织权限和OA／ERP业务通知接入的企业，可以重点评估小天互连这类企业级即时通讯平台。
这里的推荐是形成候选名单，不是预先给出性能排名。进入下一轮的产品都应提交相同口径的部署图、测试环境、容量边界、故障恢复过程和完整报价。若某个候选需要更多硬件或人工调优才能达到同一阈值，也应将这些资源计入结果。
小范围项目可以优先比较部署和维护工作量；多部门、分支机构及业务系统较多的企业，还要验证组织变化、消息可靠性、文件规则和扩容恢复。只有负载条件、测试结果和后续责任全部清楚，才能回答哪套私有化即时通讯更适合本单位。
内网即时通讯并发测试的目标，不是找出一个脱离条件的最大人数，而是明确系统在什么版本、拓扑、硬件、网络和混合业务负载下，能够达到怎样的延迟、到达率、重复率及恢复时间。先统一输入负载和输出指标，再跑日常、高峰与故障三轮测试，最后形成可签字的容量边界，候选产品才具备公平比较的基础。
对需要自有环境部署、统一员工沟通和业务通知的企业，小天互连可以进入重点候选；最终容量和交付方案仍应以本单位的测试记录为准。
