Onyx 如何用 stepramp 拐点爬升压测定位聊天服务容量上限【免费下载链接】danswerOpen Source AI Platform - AI Chat with advanced features that works with every LLM项目地址: https://gitcode.com/GitHub_Trending/da/danswer聊天服务Onyxdanswer 仓库在做容量规划时问题往往不是“固定 100 并发能不能跑”而是“用户数加到多少时系统开始跟不上”。仓库tools/loadtest/内置了一套基于 Locust 的压测装置按每个回合的里程碑首包、首个 token、整回合耗时记录延迟并且提供一个可选的ONYX_SHAPEstepramp拐点爬升形状把并发用户数按 25 → 50 → 100 → 200 这样的台阶逐级推高让系统“停止跟得上”的那个拐点直接出现在时间线上而不是靠猜一个固定并发数。本文的操作路径是装好 loadtest 依赖 → 接入确定性的 mock LLM → 创建 API key → 执行一次 stepramp 爬升 → 用 Prometheus Grafana 叠图读出拐点。前提是你有一个可被压测的 Onyx 实例并有管理员权限配置 LLM provider 与 API key。准备安装 loadtest 依赖并接入 mock LLMLocust 及其 gevent/flask 依赖树放在根pyproject.toml的可选loadtest依赖组里locust2.32等默认不同步。在仓库根目录执行uv sync --group loadtest cd tools/loadtest之后所有命令都要带--group loadtest否则裸uv run会重新同步到默认组、把 Locust 丢掉见 tools/loadtest/README.md 的 Setup 说明。压测装置的核心原则是只测 Onyx 的应用代码与基础设施在压力下的表现从不测 LLM 回答质量。因此 LLM 用仓库自带的 mock server 提供无限、零成本、确定性的调用量任何回归都能归因到 Onyx 代码uv run --group loadtest uvicorn mock_llm.app:app --port 8001然后把这个 mock 注册进 OnyxAdmin Panel → LLM或PUT /api/admin/llm/providerprovider 类型必须选openai_compatible而不是openai—— litellm 会把openai类型路由到 OpenAI Responses API 桥mock 没有实现该接口api_base指向 mock server如http://localhost:8001api_key 任意为将要使用的模型名创建 model configuration。本场景按 README 建议配慢速推理模型mock-ttft8000-itl40-len600长静默 TTFT慢 provider 会让流保持打开更久正是这种压力更早暴露 api-server 的连接/内存耗尽问题每个 model configuration 的max input tokens 需 ≥ 50,000否则默认窗口过低deep research 场景会直接拒绝低于该值的模型。mock 的行为旋钮就写在模型名里litellm 原样透传ttftms首 token 时间、itlmstoken 间隔、lenn回答长度例如mock-ttft8000-itl40-len600就是 TTFT 8 秒、token 间隔 40ms、600 token 的回答。这些名字不是真实模型必须先在 Onyx 注册为 model configuration 才能使用。创建压测用的 API key所有请求用ONYX_API_KEY作为 Bearer token。由管理员通过 Admin Panel → API Keys 创建或调用POST /api/admin/api-key并传{name: loadtest, role: basic}。下文命令中的key即指这把 key。配置并执行 stepramp 拐点爬升爬升形状实现于 shapes.py 的StepRampShape把用户数依次压在ONYX_RAMP_STAGES给出的各个平台上每个平台停留ONYX_RAMP_DWELL秒超过最后一个平台后测试停止。locustfile.py 只在检测到ONYX_SHAPEstepramp时才绑定这个形状 —— 因为 Locust 会自动激活它发现的任何 shape 并覆盖-u/-r所以不设这个环境变量时爬升不生效。相关参数均可省略默认值如下变量默认值用途ONYX_RAMP_STAGES25,50,100,200各平台的用户数逗号分隔ONYX_RAMP_DWELL300每个平台停留秒数ONYX_RAMP_SPAWN5用户生成速率README 给出的完整执行命令ONYX_SHAPEstepramp ONYX_RAMP_STAGES25,50,100,200 ONYX_RAMP_DWELL300 \ ONYX_LLM_MODELmock-ttft8000-itl40-len600 \ ONYX_API_KEYkey uv run --group loadtest locust --headless -t 25m -H https://your-onyx-url需要注意两点形状激活后-u/-r会被覆盖因此命令里不再给-u/-ryour-onyx-url必须是能服务浏览器等价路径的地址即把/api/*路由到 api server 的 URL —— 实践中就是部署的用户访问入口ingress / 负载均衡器。按 k8s/locust.yaml 的注释走 ingress 还会顺带检验 LB 空闲超时这类长流杀手。不指定任何 user class 时跑的是默认加权混合流量BasicChat 70 / ChatWithSearch 20 / MultiTool 8 / DeepResearch 2近似生产流量形态其中 ChatWithSearch 依赖已索引的文档会走 query 扩展、embedding model server 和 Vespa/OpenSearch 检索。4 个平台 × 每平台 300 秒约 20 分钟爬升所以示例用-t 25m兜住整轮。用 Prometheus 与 Grafana 读出拐点每个聊天回合会在里程碑包到达的瞬间触发命名伪请求scenario:milestoneLocust 按名字聚合分位数。与定位容量上限最相关的几个chat:first_packet—— 流的第一行服务端已接受并开始工作chat:first_answer_token—— 首个回答内容即 TTFTchat:total_turn—— 整回合墙钟时间成功/失败在这里记录。回合在以下情况判为失败非 200、流中出现错误包、流在读超时ONYX_STREAM_READ_TIMEOUT默认 180 秒指 chunk 之间的间隔而非总时长后仍无数据、或流在没有任何回答内容 / 没有stop包的情况下结束截断。master/standalone 进程会在专用端口默认9646LOCUST_PROMETHEUS_PORT可覆盖暴露/metrics实现见 prometheus_exporter.pyworker 不导出。可用指标locust_userslocust_requests_total{name,method}/locust_failures_total{name,method}locust_response_time_p50_milliseconds/locust_response_time_p95_milliseconds{name,method}locust_current_rps{name,method}采集方式取决于你的 Prometheusannotation-based 方案直接用 master pod 上的prometheus.io/scrape注解已包含在 k8s/locust.yaml 中Prometheus Operatorkube-prometheus-stack忽略注解需要 ServiceMonitor 指向metricsservice 端口 —— 该清单文件里附了注释掉的示例release标签要改成与你的 Prometheus 的serviceMonitorSelector匹配。最后一步是把指标叠成一张时间线导入 tools/loadtest/dashboards/chat-loadtest-correlation.json把里程碑延迟与失败率和服务器侧 CPU/内存画在同一时间轴上并将 dashboard 的$namespace/$workload变量设为被压测的 deployment。README 对拐点的读法就是p95 / 失败率开始上扬的那一档用户数以及最先打满的资源。台阶式爬升的好处是每一档延迟水平都对应一个固定的用户数拐点落在哪一档、被哪个资源卡住叠图上一眼可见。在目标集群内运行压测可选如果目标是 k8s 部署README 建议把整套装置跑进目标集群避免 WAN 抖动污染延迟测量、LLM 调用保持免费kubectl apply -n onyx-namespace -f k8s/mock-llm.yaml kubectl create secret generic onyx-loadtest --from-literalONYX_API_KEYkey kubectl apply -n onyx-namespace -f k8s/locust.yaml kubectl port-forward svc/onyx-loadtest-master 8089:8089然后从 8089 端口的 web UI 发起压测host、用户数、scenario 均可在 UI 指定或改 master 的 args 走 headless。注意mock 注册地址改为集群内的http://onyx-mock-llm:8000并保持is_publicfalse、persona 作用域避免真实用户看到它大并发时扩onyx-loadtest-worker副本数注释说明一个 worker 可扛数百条并发流有条件就把 worker 钉在专用节点组上别让压测生成器与被测系统抢资源清单里的镜像占位your-registry/onyx-loadtest:v0.1.0要换成你自己构建的镜像tools/loadtest/Dockerfile分布式模式下所有 pod 必须跑同一构建否则结果会被静默污染形状与场景的环境变量ONYX_SHAPE、ONYX_RAMP_STAGES、ONYX_LLM_MODEL等通过 worker 清单的env传入清单注释已注明这一配置入口并指向 README。限制与注意点README 明确st-dev 集群是 direct-RDS绝对数值与生产客户环境不同 —— 用这套结果对比不同配置之间的相对关系不要拿绝对值当 SLA 承诺st-dev 环境下/loadtest子路径被 catch-all 路由遮蔽LOCUST_HOST要指向专用 host 或用 port-forward若LOCUST_HOST走 web/nginx host健康探测路径用/api/health直连 api Service 则用/health这条主要针对 worker/threadpool 扫描场景stepramp 主路径不涉及这套压测衡量的是 Onyx 代码与基础设施回答质量不在测量范围内 —— 这是装置设计上的边界不是缺陷。跑完一轮 stepramp 后你能拿到的结论是文档定义的两个量p95/失败率开始上扬的用户数档位以及最先饱和的服务器资源。前者就是这次配置下的容量拐点后者指向上一步该调的方向worker 数、线程池、资源上限等README 的 worker concurrency sweep 一节有对应的扫描方法。【免费下载链接】danswerOpen Source AI Platform - AI Chat with advanced features that works with every LLM项目地址: https://gitcode.com/GitHub_Trending/da/danswer创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考