如何用 agentmemory 自带 load-100k 压测跑 10 万条记忆下的 p50/p90/p99 延迟与吞吐量【免费下载链接】agentmemory#1 Persistent memory for AI coding agents based on real-world benchmarks项目地址: https://gitcode.com/GitHub_Trending/age/agentmemory当有人问“10 万条记忆、并发 100 时 agentmemory 的 p99 是多少”仓库里对应的工具就是 benchmark/load-100k.ts。这是一个手写、零额外依赖的压测框架它向本地运行的 agentmemory daemon默认http://localhost:3111真实发起 HTTP 请求先用POST /agentmemory/remember写入 N 条合成记忆再对每个(N, 并发, 端点)组合记录 p50 / p90 / p99 延迟与吞吐量最后生成一份 JSON 报告。本文按文档给出的路径从启动 daemon 到拿到报告文件完整走一遍这个流程。压测实际测量什么load-100k.ts对每个测试单元cell记录以下字段写入报告中的cells数组p50_ms、p90_ms、p99_ms—— nearest-rank 百分位实现在 benchmark/lib/percentiles.tsmin_ms、max_ms、ops成功请求数、errorsthroughput_per_sec—— 该 cell 的墙钟时间 ops/sec。默认矩阵为N ∈ {1000, 10000, 100000}该 cell 运行前 daemon 里已种入的记忆条数C ∈ {1, 10, 100}cell 运行期间的并发在途请求数三个被测端点POST /agentmemory/remember、POST /agentmemory/smart-search、GET /agentmemory/memories?latesttrue。每个 cell 默认发BENCH_OPS200个请求——按 benchmark/README.md 的说法这足以稳定 p99同时不会把 100k 种子的完整跑法拖到“几十分钟以上”。文档同时强调 p99 才是容量规划该看的数p50 只能说明中位请求很快尾部用户的体感看 p99。准备条件在 agentmemory 仓库根目录工作Node 版本满足 package.json 中engines声明的node 20.0.0。一个可用的 agentmemory daemon。压测通过npm run bench:load脚本执行对应 package.json 里的node --import tsx benchmark/load-100k.ts它直接以源码方式跑 benchmark/load-100k.ts。注意一个副作用压测不是只读的——它会向 daemon 真实写入合成记忆默认全矩阵跑完最终种到 100,000 条这些内容会留在 daemon 的数据里。用独立的 daemon 实例做压测避免污染你日常使用的记忆库。启动 daemon 并确认可用在一个终端里按常规方式启动 daemonnpx agentmemory/agentmemory启动成功后可以用 health 端点确认服务在跑curl http://localhost:3111/agentmemory/health压测框架本身还会轮询GET /agentmemory/livez30 秒内不返回 2xx 就报错退出daemon at url did not become ready within 30000 ms所以 daemon 是否就绪不需要你手动判断。执行压测在另一个终端、仓库根目录下运行npm run bench:load运行时的典型 stdout 输出来自源码中的console.log逻辑实际数值以你的环境为准形如[load-100k] basehttp://localhost:3111 N1000,10000,100000 C1,10,100 ops/cell200 seed12648430 [load-100k] waiting for /agentmemory/livez (timeout 30s) [load-100k] seeding 1000 memories (target N1000) [load-100k] seeded1000 errors0 wall3.42s [load-100k] cell N1000 C1 remember ...几个执行细节值得了解N 会先升序排列种子阶段只补差量1000 → 10000 → 100000 依次“补种”所以 10 万条是在前面基础上累积写入的。如果某一轮种子请求全部失败seeded0且errors0框架会直接抛错seeding produced 0 successes ... — daemon misconfigured此时应检查 daemon 是否健康、端点是否正确。合成内容来自一个可播种的mulberry32随机数生成器BENCH_SEED相同 同一构建 字节级一致的种子语料目的是让延迟差异来自 daemon 而不是请求体抖动。覆盖默认矩阵不需要完整 3×3 矩阵时用环境变量裁剪例如只跑 N1000、并发 1 和 10、每 cell 100 个请求BENCH_N1000 BENCH_C1,10 BENCH_OPS100 npm run bench:load完整环境变量清单源自 benchmark/load-100k.ts 文件头注释变量作用默认值AGENTMEMORY_URLdaemon 基础 URLhttp://localhost:3111BENCH_N逗号分隔的 N 档位1000,10000,100000BENCH_C逗号分隔的并发档位1,10,100BENCH_OPS每 cell 的请求数200BENCH_SEEDmulberry32内容随机种子12648430BENCH_OUT_DIRJSON 报告输出目录benchmark/results/AGENTMEMORY_BENCH_AUTOSTART置1时由框架自行拉起 daemon默认假设 daemon 已在跑可选分支让框架自己拉起 daemon不想手动开终端时可以加AGENTMEMORY_BENCH_AUTOSTART1框架会用node dist/cli.js start或dist/cli.mjs拉起一个 daemonnpm run build AGENTMEMORY_BENCH_AUTOSTART1 npm run bench:load这条路径有两个前提和副作用执行前需要明确必须先执行npm run build产出dist/cli.mjs或dist/cli.js否则框架直接报错并提示先构建运行结束后框架会SIGTERM杀掉它自己拉起的 daemon2 秒内没退出再补SIGKILL。它只杀自己拉起的那个进程不会动你手动启动的 daemon。结果在哪里、怎么验证跑完后有两处产出JSON 报告写到benchmark/results/load-100k-short-git-sha.json目录不存在时框架会自行创建。文件名里的 git sha 是 best-effort 的仓库外运行时退化为时间戳。报告带schema_version: 1字段顶层包含generated_at、git_sha、base_url、seed、matrix、ops_per_cell、cells、notes。stdout 汇总表一行一个 cell列为endpoint / N / C / ops / err / p50_ms / p90_ms / p99_ms / tp/s供快速核对。仓库里已有一份真实报告 benchmark/results/load-100k-96c0ed0.json可以用它确认报告结构。它是文档示例对应N1000、C10的裁剪矩阵数值仅用于说明格式不代表 100k 规模的预期值。其三个 cell 的字段示例如下{ endpoint: POST /agentmemory/smart-search, N: 1000, C: 10, ops: 200, errors: 0, wall_ms: 3264.572, throughput_per_sec: 61.26, p50_ms: 160.064, p90_ms: 185.608, p99_ms: 224.354, min_ms: 98.498, max_ms: 251.317 }核对要点cells数量应等于len(N) × len(C) × 3每个并发档三个端点各一 cell每个 cell 的ops应接近你设置的BENCH_OPS请求失败时偏小errors偏高时先看 daemon 端日志。限制与注意事项全矩阵含 100,000 条种子耗时较长文档预期是“几十分钟”级别想先验证流程通用BENCH_N1000这类裁剪矩阵。throughput_per_sec是该 cell 的墙钟口径并发在途数就是 C单进程压测不是分布式施压。百分位算法是 nearest-rankbenchmark/lib/percentiles.ts跨项目对比时要确认对方口径一致。种入的记忆会残留在 daemon 中压测完的实例建议当作一次性实例处理或换干净数据重跑以获得可比结果。发布数字的约定按 benchmark/README.md每次发版会把一个## Performance小节追加进 CHANGELOG.md引用对应 git sha 的benchmark/results/JSONp99 是头条数字JSON 是凭证。如果你要对外给出“10 万条记忆下的延迟”走的就是这条链路npm run bench:load→ 报告 JSON → CHANGELOG 小节。【免费下载链接】agentmemory#1 Persistent memory for AI coding agents based on real-world benchmarks项目地址: https://gitcode.com/GitHub_Trending/age/agentmemory创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 如何用 agentmemory 自带 load-100k 压测跑 10 万条记忆下的 p50/p90/p99 延迟与吞吐量
如何用 agentmemory 自带 load-100k 压测跑 10 万条记忆下的 p50/p90/p99 延迟与吞吐量【免费下载链接】agentmemory#1 Persistent memory for AI coding agents based on real-world benchmarks项目地址: https://gitcode.com/GitHub_Trending/age/agentmemory当有人问“10 万条记忆、并发 100 时 agentmemory 的 p99 是多少”仓库里对应的工具就是 benchmark/load-100k.ts。这是一个手写、零额外依赖的压测框架它向本地运行的 agentmemory daemon默认http://localhost:3111真实发起 HTTP 请求先用POST /agentmemory/remember写入 N 条合成记忆再对每个(N, 并发, 端点)组合记录 p50 / p90 / p99 延迟与吞吐量最后生成一份 JSON 报告。本文按文档给出的路径从启动 daemon 到拿到报告文件完整走一遍这个流程。压测实际测量什么load-100k.ts对每个测试单元cell记录以下字段写入报告中的cells数组p50_ms、p90_ms、p99_ms—— nearest-rank 百分位实现在 benchmark/lib/percentiles.tsmin_ms、max_ms、ops成功请求数、errorsthroughput_per_sec—— 该 cell 的墙钟时间 ops/sec。默认矩阵为N ∈ {1000, 10000, 100000}该 cell 运行前 daemon 里已种入的记忆条数C ∈ {1, 10, 100}cell 运行期间的并发在途请求数三个被测端点POST /agentmemory/remember、POST /agentmemory/smart-search、GET /agentmemory/memories?latesttrue。每个 cell 默认发BENCH_OPS200个请求——按 benchmark/README.md 的说法这足以稳定 p99同时不会把 100k 种子的完整跑法拖到“几十分钟以上”。文档同时强调 p99 才是容量规划该看的数p50 只能说明中位请求很快尾部用户的体感看 p99。准备条件在 agentmemory 仓库根目录工作Node 版本满足 package.json 中engines声明的node 20.0.0。一个可用的 agentmemory daemon。压测通过npm run bench:load脚本执行对应 package.json 里的node --import tsx benchmark/load-100k.ts它直接以源码方式跑 benchmark/load-100k.ts。注意一个副作用压测不是只读的——它会向 daemon 真实写入合成记忆默认全矩阵跑完最终种到 100,000 条这些内容会留在 daemon 的数据里。用独立的 daemon 实例做压测避免污染你日常使用的记忆库。启动 daemon 并确认可用在一个终端里按常规方式启动 daemonnpx agentmemory/agentmemory启动成功后可以用 health 端点确认服务在跑curl http://localhost:3111/agentmemory/health压测框架本身还会轮询GET /agentmemory/livez30 秒内不返回 2xx 就报错退出daemon at url did not become ready within 30000 ms所以 daemon 是否就绪不需要你手动判断。执行压测在另一个终端、仓库根目录下运行npm run bench:load运行时的典型 stdout 输出来自源码中的console.log逻辑实际数值以你的环境为准形如[load-100k] basehttp://localhost:3111 N1000,10000,100000 C1,10,100 ops/cell200 seed12648430 [load-100k] waiting for /agentmemory/livez (timeout 30s) [load-100k] seeding 1000 memories (target N1000) [load-100k] seeded1000 errors0 wall3.42s [load-100k] cell N1000 C1 remember ...几个执行细节值得了解N 会先升序排列种子阶段只补差量1000 → 10000 → 100000 依次“补种”所以 10 万条是在前面基础上累积写入的。如果某一轮种子请求全部失败seeded0且errors0框架会直接抛错seeding produced 0 successes ... — daemon misconfigured此时应检查 daemon 是否健康、端点是否正确。合成内容来自一个可播种的mulberry32随机数生成器BENCH_SEED相同 同一构建 字节级一致的种子语料目的是让延迟差异来自 daemon 而不是请求体抖动。覆盖默认矩阵不需要完整 3×3 矩阵时用环境变量裁剪例如只跑 N1000、并发 1 和 10、每 cell 100 个请求BENCH_N1000 BENCH_C1,10 BENCH_OPS100 npm run bench:load完整环境变量清单源自 benchmark/load-100k.ts 文件头注释变量作用默认值AGENTMEMORY_URLdaemon 基础 URLhttp://localhost:3111BENCH_N逗号分隔的 N 档位1000,10000,100000BENCH_C逗号分隔的并发档位1,10,100BENCH_OPS每 cell 的请求数200BENCH_SEEDmulberry32内容随机种子12648430BENCH_OUT_DIRJSON 报告输出目录benchmark/results/AGENTMEMORY_BENCH_AUTOSTART置1时由框架自行拉起 daemon默认假设 daemon 已在跑可选分支让框架自己拉起 daemon不想手动开终端时可以加AGENTMEMORY_BENCH_AUTOSTART1框架会用node dist/cli.js start或dist/cli.mjs拉起一个 daemonnpm run build AGENTMEMORY_BENCH_AUTOSTART1 npm run bench:load这条路径有两个前提和副作用执行前需要明确必须先执行npm run build产出dist/cli.mjs或dist/cli.js否则框架直接报错并提示先构建运行结束后框架会SIGTERM杀掉它自己拉起的 daemon2 秒内没退出再补SIGKILL。它只杀自己拉起的那个进程不会动你手动启动的 daemon。结果在哪里、怎么验证跑完后有两处产出JSON 报告写到benchmark/results/load-100k-short-git-sha.json目录不存在时框架会自行创建。文件名里的 git sha 是 best-effort 的仓库外运行时退化为时间戳。报告带schema_version: 1字段顶层包含generated_at、git_sha、base_url、seed、matrix、ops_per_cell、cells、notes。stdout 汇总表一行一个 cell列为endpoint / N / C / ops / err / p50_ms / p90_ms / p99_ms / tp/s供快速核对。仓库里已有一份真实报告 benchmark/results/load-100k-96c0ed0.json可以用它确认报告结构。它是文档示例对应N1000、C10的裁剪矩阵数值仅用于说明格式不代表 100k 规模的预期值。其三个 cell 的字段示例如下{ endpoint: POST /agentmemory/smart-search, N: 1000, C: 10, ops: 200, errors: 0, wall_ms: 3264.572, throughput_per_sec: 61.26, p50_ms: 160.064, p90_ms: 185.608, p99_ms: 224.354, min_ms: 98.498, max_ms: 251.317 }核对要点cells数量应等于len(N) × len(C) × 3每个并发档三个端点各一 cell每个 cell 的ops应接近你设置的BENCH_OPS请求失败时偏小errors偏高时先看 daemon 端日志。限制与注意事项全矩阵含 100,000 条种子耗时较长文档预期是“几十分钟”级别想先验证流程通用BENCH_N1000这类裁剪矩阵。throughput_per_sec是该 cell 的墙钟口径并发在途数就是 C单进程压测不是分布式施压。百分位算法是 nearest-rankbenchmark/lib/percentiles.ts跨项目对比时要确认对方口径一致。种入的记忆会残留在 daemon 中压测完的实例建议当作一次性实例处理或换干净数据重跑以获得可比结果。发布数字的约定按 benchmark/README.md每次发版会把一个## Performance小节追加进 CHANGELOG.md引用对应 git sha 的benchmark/results/JSONp99 是头条数字JSON 是凭证。如果你要对外给出“10 万条记忆下的延迟”走的就是这条链路npm run bench:load→ 报告 JSON → CHANGELOG 小节。【免费下载链接】agentmemory#1 Persistent memory for AI coding agents based on real-world benchmarks项目地址: https://gitcode.com/GitHub_Trending/age/agentmemory创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考