SpacetimeDB 应用性能基准工具指南用 LLM 生成的 PG / STDB / Mongo 聊天应用实测吞吐与延迟【免费下载链接】SpacetimeDBDevelopment at the speed of light项目地址: https://gitcode.com/GitHub_Trending/sp/SpacetimeDB在 SpacetimeDB 仓库的 tools/llm-sequential-upgrade/perf-benchmark/README.md 中维护着一套面向顺序升级基准sequential upgrade benchmark的运行时性能压测工具。它的核心定位非常独特不做 PostgreSQL 与 SpacetimeDB 的合成基准对比而是评测 LLM 在 Level 12 阶段实际生成的聊天应用代码——让这些应用以出厂原样跑在同机本地数据库上测量每秒消息吞吐与端到端延迟。读完本文你将掌握这套工具的场景设计、安装步骤、CLI 参数、指标口径与结果解读方法并能复跑出可用于展示的对比数据。这套基准测的是什么工具所处的tools/llm-sequential-upgrade/perf-benchmark/目录是 tools/llm-sequential-upgrade 顺序升级流水线的一部分。其动机在 README 中写得很明确为营销一页纸marketing one-pager提供展示数据因此只关心由 LLM 构建的应用在两种技术栈上的运行时表现而不是后端引擎本身的极限。这意味着两件事被测对象是应用不是引擎。基准驱动的是 LLM 生成的应用接口PG 的 Express Socket.io 服务、STDB 的 reducer、Mongo 的 MERN 应用而不是对数据库内核的合成 SQL 压测。结果反映出厂即所得。代码未经手工重写所以 PG 应用里的每消息 5 次串行 DB 查询、STDB reducer 的单事务提交都会如实反映在数字里。这正是该工具的价值展示同一份 prompt 下LLM 在不同栈上自然写出的代码结构差异会如何放大性能差距。工具支持三种后端由三个客户端适配器驱动postgres-client.ts —— Express Socket.ioPOST /api/users、POST /api/rooms、socket.emit(send_message)等spacetime-client.ts —— 基于spacetimedbnpm 包的DbConnection调用生成的setName/createRoom/joinRoom/sendMessagereducermongodb-client.ts —— MERN 应用身份是用户名字符串发消息走 RESTPOST /api/rooms/:roomId/messages。两种测试场景README 给出了场景定义代码分别实现在 stress-throughput.ts 与 realistic-chat.ts场景行为测量指标stressN 个 writer 以最快速度持续调用send_message持续 D 秒持续 msgs/sec p99 延迟realisticM 个用户按人类节奏发消息5~15 秒随机抖动持续 D 秒真实负载下的持续 msgs/sec 与延迟在代码层面两个场景的编排方式一致先创建 N 个 writerPG/Mongo 用 REST 建用户STDB 用匿名连接建名统一建一个公共房间并全员加入随后进入测量窗口循环发消息结束时排空drain3 秒左右再关闭连接。其中stress场景针对各后端有专门的工程细节PG先在 socket 上做 warmup 探测——若 1.5 秒内没有 echo 返回则自动切换到 REST 模式POST /api/rooms/:id/messages兼容 20260403 与 20260406 两代 LLM 生成的 API 形状socket 模式下用inflight表跟踪未回显消息以服务器插入并广播回自己的往返作为 ack。STDB刻意禁用了 listener 订阅因为同一 Node 事件循环上fan-out 处理会与 writer 的 ack 处理竞争成为客户端侧瓶颈ack 取自 reducer Promise 的 resolve即服务器事务已提交。每个 writer 使用subscriptions: []跳过默认订阅集避免同步约 7 万条历史消息行压测循环采用MAX_INFLIGHT_PER_WORKER 10的管道式写法让多个 reducer 调用并发在途STDB 会在 WebSocket 上批处理能容纳远多于 PG 的在途请求。Mongoack 即 POST HTTP 往返服务器插入并响应fan-out 由独立 listener socket 测量received若因 listener 事件循环瓶颈为 0则回退用ackedSends计算吞吐。安装与准备先安装依赖package.json 中依赖socket.io-client、spacetimedb、tsx、typescript通过npm run run即tsx src/main.ts启动npm install # 针对目标 Level 12 应用的后端重新生成 SpacetimeDB 绑定。 # 切换被测应用后必须重新执行。 spacetime generate --lang typescript --out-dir src/module_bindings \ --module-path ../sequential-upgrade/sequential-upgrade-20260406/spacetime/results/chat-app-20260406-153727/backend/spacetimedb生成的绑定落在 src/module_bindings 下spacetime-client.ts依赖其中的DbConnection、reducer 与表访问器。当前仓库已包含一份针对 20260406 聊天应用生成的绑定send_message_reducer.ts、message_table.ts、user_table.ts等一整套可直接对照阅读。运行前置条件被测应用必须已在运行——Postgres进入pg-app/server执行npm run devExpress 监听:6001并保证exhaust-test-postgres-1Docker 容器在线端口 6432。SpacetimeDB本地spacetime start运行且目标模块已发布应用生成时会自动发布自身。运行命令与 CLI 参数README 给出三条典型命令# PG stress30 秒20 个 writer npm run run -- --backend pg --scenario stress --writers 20 --duration 30 # STDB stress30 秒50 个 writer必须指定 --module npm run run -- --backend stdb --scenario stress --writers 50 --duration 30 \ --module chat-app-20260406-153727 # 某个后端跑完两种吞吐场景 npm run run -- --backend pg --scenario all npm run run -- --backend stdb --scenario all --module chat-app-20260406-153727完整的参数表可在 main.ts 的parseArgs中确认默认值如下参数含义默认值--backendpg/stdb/mongopg--scenariostress/realistic/allstress--pg-urlPG 服务地址http://localhost:6001--mongo-urlMongo 服务地址http://localhost:6001--stdb-uriSTDB WebSocket 地址ws://localhost:3000--moduleSTDB 模块名stdb 必填空缺省会直接报错--writersstress 场景 writer 数20--usersrealistic 场景用户数50--duration压测持续秒数30--out结果输出目录results/时间戳--scenario all会依次执行stress与realistic两个场景。realistic场景的发送间隔在 realistic-chat.ts 中固定为 5 000~15 000ms 的均匀随机抖动jitter(min, max)对应 README 中人类节奏的定义。结果输出与指标口径每次运行会创建results/timestamp/目录--out可覆盖每个场景写入一个backend-scenario.json。README 中还提到优化参考快照保存在results/optimized-reference/参考实现与方法论位于optimized-reference/。JSON 的结构定义在 metrics.ts 的ScenarioResult接口中包含scenario、backend、startedAt、durationSec、writerssent/received/errorsmsgsPerSecreceived / durationSecackLatencyMs与fanoutLatencyMs两个延迟摘要min/max/mean/p50/p95/p99/p999count由LatencyHistogram聚合原始毫秒样本后按需排序计算分位数。ack 与 fan-out 的口径差异值得细说ack latencyPG 取发送 → 服务器插入并广播回自己的 echo 往返STDB 取 reducer Promise resolve服务器事务提交确认Mongo 取 POST HTTP 往返。fan-out latency统一由独立 listener 连接在同一房间内接收广播用嵌入消息文本的时间戳计算端到端分播延迟。metrics.ts的stampMessage会把process.hrtime.bigint()的高精度纳秒时间戳与序号编码进消息文本前缀__bench:listener 收到后用parseStamp解析并用nsToMs换算毫秒。跨机时钟问题的规避所有客户端连接都在同一 Node 进程中共享同一个时钟process.hrtime因此 fan-out 延迟不存在多机时钟偏差直接可比。results/目录下的多个 JSON 还可以用 generate-summary.ts 合并成对比报告# 依次传入 PG 结果目录、STDB 结果目录、输出目录 tsx src/generate-summary.ts results/full-pg results/full-stdb results该脚本会生成summary.md与summary.json按场景输出 PG 与 STDB 的吞吐、接收消息数、fan-out p50/p99、ack p50/p99 对比表并自动计算 stress 场景下的吞吐倍率 headline。必须注意的公平性与测量边界README 的 Caveats 部分划定了结论的适用范围代码与优化参考文档同样反复强调PG 应用存在 500ms/用户的发送限流send_message处理程序在应用层限流见 postgres-client.ts 的注释因此单个 PG writer 至多约 2 msgs/sec吞吐只能靠增加 writer 数线性扩展压测工具按 ~510ms 间隔节奏发送 writer 以避免丢消息。STDB 没有等价限流单 writer 上限高得多——因此 stress 场景的 PG 与 STDB 吞吐不可直接按单机能力解读STDB 的数字天然占优Mongo 应用同样无限流mongodb-client.ts明确提示stress 数字不与 PG stress 直接可比apples-to-apples 比较请用 realistic 场景。数据来自单开发机 本地数据库反映的是LLM 交付的应用在当时的运行环境中的表现不是任何后端的理论天花板所有连接共享同一 Node 时钟fan-out 延迟有意义无跨机时钟偏差。Mongo 数据存在跨机器/跨批次 caveat优化参考文档 METHODOLOGY.md 指出STDB 与 PG 数据来自 20260406 批次Mongo 数据来自 20260616 的另一台机器同批内的 raw→optimized 比例约 1.7x是干净的跨后端的绝对数字并非同一会话测得且 PG 有限流、Mongo 无限流PG 吞吐被限流压制。优化参考实现与历史基准数据optimized-reference/目录保存了sendMessage处理器的优化参考版pg-index-optimized.ts、stdb-index-optimized.ts、mongo-index-optimized.ts、mongo-models-optimized.ts。以 stdb-index-optimized.ts 为例功能与 AI 生成版完全一致仅实现方式变化成员检查改用roomMember.userIdentity.filter(ctx.sender)命中 identity 索引替代按 roomId 过滤 [...spread]toHexString()字符串分配的写法已读回执read receipt更新与 typing indicator 清理同样改用 identity 索引、避免展开与字符串分配用户存在性、房间存在性、消息插入、全部校验逻辑均保留。PG 与 Mongo 的优化方向则是把阻塞路径缩短如 PG 将lastSeen更新与通知 fan-out 查询改为 fire-without-awaitMongo由一次独立的 first-principles 重构得到将连接池maxPoolSize5→20、插入后先回 HTTP 响应再延迟 socket 广播、读接口加.lean()、加复合索引{ roomId, parentId, createdAt }、关闭perMessageDeflate等。METHODOLOGY.md 记录了两次运行平均、同一 20260406 机器版本STDBPG倍率RawAI 生成原样5,267 msgs/sec694 msgs/sec7.6xOptimized25,278 msgs/sec1,139 msgs/sec22x并附注Mongo 峰值约为 raw ~800、optimized ~1,400 msgs/sec20260616 机器优化增益 ~1.7x与 PG 的 1.6x 同量级STDB 的 4.8x 优化增益反映了更多的架构空间。引用这些数字时必须保留其边界条件单机、本地库、LLM 生成代码原样运行且 Mongo 为跨机数据。写在最后如何正确使用这套工具换被测应用时务必重新执行spacetime generate并核对--module名称否则 STDB 连接会因绑定/模块不匹配而失败对比公平性优先使用realistic场景人类节奏、远低于限流阈值stress场景用于观察各栈在无节流洪水下的架构行为但要意识到 PG 应用层限流与 STDB 无等价限流这一不对称前提结果文件是结构化的ScenarioResultJSON可直接用 generate-summary.ts 生成对比摘要也可自行二次分析 ack 与 fan-out 的完整分位分布参考 METHODOLOGY.md 理解 raw 与 optimized 两个对比点的实现差异所有结论都应限定在LLM 生成应用 单机本地库的证据边界内。【免费下载链接】SpacetimeDBDevelopment at the speed of light项目地址: https://gitcode.com/GitHub_Trending/sp/SpacetimeDB创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 SpacetimeDB 应用性能基准工具指南：用 LLM 生成的 PG / STDB / Mongo 聊天应用实测吞吐与延迟
SpacetimeDB 应用性能基准工具指南用 LLM 生成的 PG / STDB / Mongo 聊天应用实测吞吐与延迟【免费下载链接】SpacetimeDBDevelopment at the speed of light项目地址: https://gitcode.com/GitHub_Trending/sp/SpacetimeDB在 SpacetimeDB 仓库的 tools/llm-sequential-upgrade/perf-benchmark/README.md 中维护着一套面向顺序升级基准sequential upgrade benchmark的运行时性能压测工具。它的核心定位非常独特不做 PostgreSQL 与 SpacetimeDB 的合成基准对比而是评测 LLM 在 Level 12 阶段实际生成的聊天应用代码——让这些应用以出厂原样跑在同机本地数据库上测量每秒消息吞吐与端到端延迟。读完本文你将掌握这套工具的场景设计、安装步骤、CLI 参数、指标口径与结果解读方法并能复跑出可用于展示的对比数据。这套基准测的是什么工具所处的tools/llm-sequential-upgrade/perf-benchmark/目录是 tools/llm-sequential-upgrade 顺序升级流水线的一部分。其动机在 README 中写得很明确为营销一页纸marketing one-pager提供展示数据因此只关心由 LLM 构建的应用在两种技术栈上的运行时表现而不是后端引擎本身的极限。这意味着两件事被测对象是应用不是引擎。基准驱动的是 LLM 生成的应用接口PG 的 Express Socket.io 服务、STDB 的 reducer、Mongo 的 MERN 应用而不是对数据库内核的合成 SQL 压测。结果反映出厂即所得。代码未经手工重写所以 PG 应用里的每消息 5 次串行 DB 查询、STDB reducer 的单事务提交都会如实反映在数字里。这正是该工具的价值展示同一份 prompt 下LLM 在不同栈上自然写出的代码结构差异会如何放大性能差距。工具支持三种后端由三个客户端适配器驱动postgres-client.ts —— Express Socket.ioPOST /api/users、POST /api/rooms、socket.emit(send_message)等spacetime-client.ts —— 基于spacetimedbnpm 包的DbConnection调用生成的setName/createRoom/joinRoom/sendMessagereducermongodb-client.ts —— MERN 应用身份是用户名字符串发消息走 RESTPOST /api/rooms/:roomId/messages。两种测试场景README 给出了场景定义代码分别实现在 stress-throughput.ts 与 realistic-chat.ts场景行为测量指标stressN 个 writer 以最快速度持续调用send_message持续 D 秒持续 msgs/sec p99 延迟realisticM 个用户按人类节奏发消息5~15 秒随机抖动持续 D 秒真实负载下的持续 msgs/sec 与延迟在代码层面两个场景的编排方式一致先创建 N 个 writerPG/Mongo 用 REST 建用户STDB 用匿名连接建名统一建一个公共房间并全员加入随后进入测量窗口循环发消息结束时排空drain3 秒左右再关闭连接。其中stress场景针对各后端有专门的工程细节PG先在 socket 上做 warmup 探测——若 1.5 秒内没有 echo 返回则自动切换到 REST 模式POST /api/rooms/:id/messages兼容 20260403 与 20260406 两代 LLM 生成的 API 形状socket 模式下用inflight表跟踪未回显消息以服务器插入并广播回自己的往返作为 ack。STDB刻意禁用了 listener 订阅因为同一 Node 事件循环上fan-out 处理会与 writer 的 ack 处理竞争成为客户端侧瓶颈ack 取自 reducer Promise 的 resolve即服务器事务已提交。每个 writer 使用subscriptions: []跳过默认订阅集避免同步约 7 万条历史消息行压测循环采用MAX_INFLIGHT_PER_WORKER 10的管道式写法让多个 reducer 调用并发在途STDB 会在 WebSocket 上批处理能容纳远多于 PG 的在途请求。Mongoack 即 POST HTTP 往返服务器插入并响应fan-out 由独立 listener socket 测量received若因 listener 事件循环瓶颈为 0则回退用ackedSends计算吞吐。安装与准备先安装依赖package.json 中依赖socket.io-client、spacetimedb、tsx、typescript通过npm run run即tsx src/main.ts启动npm install # 针对目标 Level 12 应用的后端重新生成 SpacetimeDB 绑定。 # 切换被测应用后必须重新执行。 spacetime generate --lang typescript --out-dir src/module_bindings \ --module-path ../sequential-upgrade/sequential-upgrade-20260406/spacetime/results/chat-app-20260406-153727/backend/spacetimedb生成的绑定落在 src/module_bindings 下spacetime-client.ts依赖其中的DbConnection、reducer 与表访问器。当前仓库已包含一份针对 20260406 聊天应用生成的绑定send_message_reducer.ts、message_table.ts、user_table.ts等一整套可直接对照阅读。运行前置条件被测应用必须已在运行——Postgres进入pg-app/server执行npm run devExpress 监听:6001并保证exhaust-test-postgres-1Docker 容器在线端口 6432。SpacetimeDB本地spacetime start运行且目标模块已发布应用生成时会自动发布自身。运行命令与 CLI 参数README 给出三条典型命令# PG stress30 秒20 个 writer npm run run -- --backend pg --scenario stress --writers 20 --duration 30 # STDB stress30 秒50 个 writer必须指定 --module npm run run -- --backend stdb --scenario stress --writers 50 --duration 30 \ --module chat-app-20260406-153727 # 某个后端跑完两种吞吐场景 npm run run -- --backend pg --scenario all npm run run -- --backend stdb --scenario all --module chat-app-20260406-153727完整的参数表可在 main.ts 的parseArgs中确认默认值如下参数含义默认值--backendpg/stdb/mongopg--scenariostress/realistic/allstress--pg-urlPG 服务地址http://localhost:6001--mongo-urlMongo 服务地址http://localhost:6001--stdb-uriSTDB WebSocket 地址ws://localhost:3000--moduleSTDB 模块名stdb 必填空缺省会直接报错--writersstress 场景 writer 数20--usersrealistic 场景用户数50--duration压测持续秒数30--out结果输出目录results/时间戳--scenario all会依次执行stress与realistic两个场景。realistic场景的发送间隔在 realistic-chat.ts 中固定为 5 000~15 000ms 的均匀随机抖动jitter(min, max)对应 README 中人类节奏的定义。结果输出与指标口径每次运行会创建results/timestamp/目录--out可覆盖每个场景写入一个backend-scenario.json。README 中还提到优化参考快照保存在results/optimized-reference/参考实现与方法论位于optimized-reference/。JSON 的结构定义在 metrics.ts 的ScenarioResult接口中包含scenario、backend、startedAt、durationSec、writerssent/received/errorsmsgsPerSecreceived / durationSecackLatencyMs与fanoutLatencyMs两个延迟摘要min/max/mean/p50/p95/p99/p999count由LatencyHistogram聚合原始毫秒样本后按需排序计算分位数。ack 与 fan-out 的口径差异值得细说ack latencyPG 取发送 → 服务器插入并广播回自己的 echo 往返STDB 取 reducer Promise resolve服务器事务提交确认Mongo 取 POST HTTP 往返。fan-out latency统一由独立 listener 连接在同一房间内接收广播用嵌入消息文本的时间戳计算端到端分播延迟。metrics.ts的stampMessage会把process.hrtime.bigint()的高精度纳秒时间戳与序号编码进消息文本前缀__bench:listener 收到后用parseStamp解析并用nsToMs换算毫秒。跨机时钟问题的规避所有客户端连接都在同一 Node 进程中共享同一个时钟process.hrtime因此 fan-out 延迟不存在多机时钟偏差直接可比。results/目录下的多个 JSON 还可以用 generate-summary.ts 合并成对比报告# 依次传入 PG 结果目录、STDB 结果目录、输出目录 tsx src/generate-summary.ts results/full-pg results/full-stdb results该脚本会生成summary.md与summary.json按场景输出 PG 与 STDB 的吞吐、接收消息数、fan-out p50/p99、ack p50/p99 对比表并自动计算 stress 场景下的吞吐倍率 headline。必须注意的公平性与测量边界README 的 Caveats 部分划定了结论的适用范围代码与优化参考文档同样反复强调PG 应用存在 500ms/用户的发送限流send_message处理程序在应用层限流见 postgres-client.ts 的注释因此单个 PG writer 至多约 2 msgs/sec吞吐只能靠增加 writer 数线性扩展压测工具按 ~510ms 间隔节奏发送 writer 以避免丢消息。STDB 没有等价限流单 writer 上限高得多——因此 stress 场景的 PG 与 STDB 吞吐不可直接按单机能力解读STDB 的数字天然占优Mongo 应用同样无限流mongodb-client.ts明确提示stress 数字不与 PG stress 直接可比apples-to-apples 比较请用 realistic 场景。数据来自单开发机 本地数据库反映的是LLM 交付的应用在当时的运行环境中的表现不是任何后端的理论天花板所有连接共享同一 Node 时钟fan-out 延迟有意义无跨机时钟偏差。Mongo 数据存在跨机器/跨批次 caveat优化参考文档 METHODOLOGY.md 指出STDB 与 PG 数据来自 20260406 批次Mongo 数据来自 20260616 的另一台机器同批内的 raw→optimized 比例约 1.7x是干净的跨后端的绝对数字并非同一会话测得且 PG 有限流、Mongo 无限流PG 吞吐被限流压制。优化参考实现与历史基准数据optimized-reference/目录保存了sendMessage处理器的优化参考版pg-index-optimized.ts、stdb-index-optimized.ts、mongo-index-optimized.ts、mongo-models-optimized.ts。以 stdb-index-optimized.ts 为例功能与 AI 生成版完全一致仅实现方式变化成员检查改用roomMember.userIdentity.filter(ctx.sender)命中 identity 索引替代按 roomId 过滤 [...spread]toHexString()字符串分配的写法已读回执read receipt更新与 typing indicator 清理同样改用 identity 索引、避免展开与字符串分配用户存在性、房间存在性、消息插入、全部校验逻辑均保留。PG 与 Mongo 的优化方向则是把阻塞路径缩短如 PG 将lastSeen更新与通知 fan-out 查询改为 fire-without-awaitMongo由一次独立的 first-principles 重构得到将连接池maxPoolSize5→20、插入后先回 HTTP 响应再延迟 socket 广播、读接口加.lean()、加复合索引{ roomId, parentId, createdAt }、关闭perMessageDeflate等。METHODOLOGY.md 记录了两次运行平均、同一 20260406 机器版本STDBPG倍率RawAI 生成原样5,267 msgs/sec694 msgs/sec7.6xOptimized25,278 msgs/sec1,139 msgs/sec22x并附注Mongo 峰值约为 raw ~800、optimized ~1,400 msgs/sec20260616 机器优化增益 ~1.7x与 PG 的 1.6x 同量级STDB 的 4.8x 优化增益反映了更多的架构空间。引用这些数字时必须保留其边界条件单机、本地库、LLM 生成代码原样运行且 Mongo 为跨机数据。写在最后如何正确使用这套工具换被测应用时务必重新执行spacetime generate并核对--module名称否则 STDB 连接会因绑定/模块不匹配而失败对比公平性优先使用realistic场景人类节奏、远低于限流阈值stress场景用于观察各栈在无节流洪水下的架构行为但要意识到 PG 应用层限流与 STDB 无等价限流这一不对称前提结果文件是结构化的ScenarioResultJSON可直接用 generate-summary.ts 生成对比摘要也可自行二次分析 ack 与 fan-out 的完整分位分布参考 METHODOLOGY.md 理解 raw 与 optimized 两个对比点的实现差异所有结论都应限定在LLM 生成应用 单机本地库的证据边界内。【免费下载链接】SpacetimeDBDevelopment at the speed of light项目地址: https://gitcode.com/GitHub_Trending/sp/SpacetimeDB创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考