尧图网站建设 
如何用 Turso 吞吐基准测试测量并发写入事务的每秒事务数【免费下载链接】tursoA SQL database in Rust: SQLite-compatible, now also speaking Postgres (experimental). The LLVM of databases.项目地址: https://gitcode.com/GitHub_Trending/tu/turso仓库里的perf/throughput目录提供了txn-throughput基准测试用来测量 SQLite 和 Turso 在多个连接同时写入时每秒能提交多少小写入事务transactions per second。它把连接数当作同时执行的事务数逐步扫过从 1 个一直扫到远超 CPU 核心数的范围并把每个吞吐点与进程 CPU 占用、磁盘活动和 checkpoint 耗时放在一起报告。本文按文档给出的路径从环境准备、快速试跑、完整基准到结果读取和正确性校验走通一次测量。这个基准到底在测什么测量方式是闭环closed loop每个连接在上一笔事务提交后立即开始下一笔因此连接数就等于在途事务数。吞吐量定义为测量窗口内开始的事务数除以窗口时长所有引擎和配置使用相同的墙钟时间且包含 checkpoint 阶段。关键设定来自 perf/throughput/README.md单表test_table(id INTEGER PRIMARY KEY, data TEXT)每个事务插入BATCH_SIZE行默认 100id 来自所有连接共享的计数器事务之间不触碰同一行竞争只发生在引擎自身写入路径上两个引擎都运行PRAGMA synchronous FULL每次 commit 都以 fsync 结束SQLite 侧使用 WAL 模式、每连接一个线程通过rusqlite和BEGIN IMMEDIATETurso 侧使用 MVCCPRAGMA journal_mode mvcc、每连接一个独立 tokio runtime、BEGIN CONCURRENTLinux 上使用 io_uring 后端写连接的 auto-checkpoint 关闭由独立连接每CHECKPOINTER毫秒默认 1000执行一次PRAGMA wal_checkpoint(PASSIVE)与服务器实际行为一致。每笔事务的 begin、work、commit 耗时都会被记录重启restarted次数计入其服务时间。准备条件README 列出的环境要求Rust 工具链脚本通过cargo build --release -p txn-throughput构建测试框架uv用于绘制结果图Linux供 Turso 的 io_uring 后端使用可sudo的账号每轮运行前脚本会执行sudo fstrim和echo 3 | sudo tee /proc/sys/vm/drop_caches。最后一条有实际副作用fstrim会向数据库所在挂载点的磁盘发出 TRIM 命令drop_caches会丢弃系统 page cache。文档说明这样做的目的是让消费者级 SSD 在空闲期排空写缓存、避免后一轮继承前一轮的写积压如果你不希望修改磁盘状态或没有 root 权限这一步无法省略也就不能直接跑完整的run.sh流程可改为直接运行单次 harness见下文可选直接运行单次 harness。txn-throughput是 cargo workspace 的成员见根 Cargo.toml 中perf/throughput所以在仓库根目录下即可完成构建。另外 scripts/bench.sh 通过git rev-parse --show-toplevel定位仓库根目录需要在 git 检出中运行。快速试跑缩短参数验证流程完整基准耗时很长先用文档给出的缩短配置跑一遍确认工具链、sudo 和输出路径都正常CONNS1 8 64 REPEATS2 DURATION10 IDLE5 ./scripts/run.sh命令在perf/throughput目录下执行。含义只在 1、8、64 三个连接数上各跑 2 次每次只测量 10 秒默认 30 秒fstrim后只空闲 5 秒默认 30 秒。环境变量由 scripts/bench.sh 读取run.sh调用它因此两个入口都接受这些变量。完整基准./scripts/run.sh不带任何变量会在 1、2、4、8、16、32、64 个连接上各跑 3 次并绘图。README 估计耗时约一小时其中一半是每轮运行前 30 秒的磁盘空闲等待而 scripts/run.sh 的注释写的是约两小时。两处口径不一致按较保守的估计预留时间即可。可选直接运行单次 harness如果想跑单个引擎、单个连接数的配置而不走脚本先构建再直接调用二进制。scripts/bench.sh 展示的构建和调用方式为cargo build --release -p txn-throughput二进制默认位于 cargo target 的release目录脚本通过仓库自带的scripts/cargo-target-dir查询实际位置尊重CARGO_TARGET_DIR。参数与 bench.sh 中一致cargo run --release -p txn-throughput -- \ --engine turso --connections 16 \ --batch-size 100 --checkpointer 1000 \ --duration 30 --warmup 3 --run 1 \ --db-dir ./db --out-dir ./plot--engine取sqlite或turso。--db-dir存放数据库文件--out-dir存放结果文件每次运行会写入自己的文件拒绝覆盖已存在的文件拒绝时提示already exists; remove it or pass another --db-dir/--out-dir。txn-throughput --help列出了全部选项其中与对比相关的两个--mode immediate让 Turso 以 WAL BEGIN IMMEDIATE运行与 SQLite 相同的单写者路径SQLite 只支持immediate模式--io syscall切换 Turso 的 IO 后端Linux 上默认io_uring非 Linux 默认syscall见 main.rs 中的DEFAULT_IO。如何读到每秒事务数一次完整运行结束后TPS 出现在三处终端与plot/bench.log每轮运行打印摘要形如{引擎} transactions, {行数} rows in {秒} s: {transactions/s}, {rows/s}随后是服务时间分位数p50/p99/p99.9/max、CPUuser、sys、占一个核心的百分比、占全部硬件线程的百分比、每事务微秒数、磁盘写入统计和 checkpoint 的 p50/max 耗时。bench.log开头还记录机器型号、硬件线程数、内核版本和磁盘信息方便复现时对照环境plot/engine-cconnections-rrun-result.csv每轮一行包含transactions_per_s、rows_per_s、cpu_us_per_transaction、restarts、各分位数、磁盘写入量与 checkpoint 统计plot/throughput.png及.pdf、.tikz左轴是 TPS 随连接数的变化右轴0–100%是进程 CPU 占全部硬件线程的份额每个点是各次运行的均值并带一个标准差的误差棒。run.sh在跑完全部配置后用uv run plot/plot-throughput.py自动生成这三份图。另外每轮还会写三个明细 CSV...-rrun.csv记录每个事务的开始时刻、是否预热、重启次数和 begin/work/commit 耗时...-timeline.csv按秒记录每秒提交的事务数和 CPU 占用...-checkpoints.csv记录每次 checkpoint 的开始时刻与耗时。所有数据库文件保留在db/timestamp/下脚本不会删除任何历史文件。结果可信度如何判断harness 自带一次正确性校验运行结束后通过一条全新连接对表做SELECT count(*)行数必须等于已提交事务数乘以BATCH_SIZE不一致时打印the table holds N rows but M transactions of B rows committed并以退出码 1 结束见 main.rs。所以一次运行跑完且退出码为 0本身就包含了落盘数据完整性的检查bench.sh也把每一轮 harness 的退出状态单独取出非 0 即整体终止。解读结果时的两个文档提示每轮都从一个全新的空数据库文件开始测量 30 秒前有 3 秒预热预热期的事务会被记录但标记为 warmup不参与汇总和绘图奇数次重复按连接数从小到大扫描偶数次从大到小顺序效应会体现为两者的差异——对比结果时应成对看而不是只取某一次。限制与不适用情况该流程要求能执行sudo fstrim与清空 page cache缺少相应权限时不能按文档路径复现完整基准磁盘统计来自/proc/diskstats仅在 Linux 上可用输出目录中若已有同名结果文件运行会拒绝覆盖而不是静默替换重跑时换OUT/DB_DIR或先移走旧文件仓库本身只读约束下在自有检出中操作。如果只需要单次配置的 TPS 而非完整对比曲线直接用上文单次 harness的路径需要 SQLite 与 Turso 全连接数扫描加绘图时主路径就是./scripts/run.sh。【免费下载链接】tursoA SQL database in Rust: SQLite-compatible, now also speaking Postgres (experimental). The LLVM of databases.项目地址: https://gitcode.com/GitHub_Trending/tu/turso创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 如何用 Turso 吞吐基准测试测量并发写入事务的每秒事务数？
如何用 Turso 吞吐基准测试测量并发写入事务的每秒事务数【免费下载链接】tursoA SQL database in Rust: SQLite-compatible, now also speaking Postgres (experimental). The LLVM of databases.项目地址: https://gitcode.com/GitHub_Trending/tu/turso仓库里的perf/throughput目录提供了txn-throughput基准测试用来测量 SQLite 和 Turso 在多个连接同时写入时每秒能提交多少小写入事务transactions per second。它把连接数当作同时执行的事务数逐步扫过从 1 个一直扫到远超 CPU 核心数的范围并把每个吞吐点与进程 CPU 占用、磁盘活动和 checkpoint 耗时放在一起报告。本文按文档给出的路径从环境准备、快速试跑、完整基准到结果读取和正确性校验走通一次测量。这个基准到底在测什么测量方式是闭环closed loop每个连接在上一笔事务提交后立即开始下一笔因此连接数就等于在途事务数。吞吐量定义为测量窗口内开始的事务数除以窗口时长所有引擎和配置使用相同的墙钟时间且包含 checkpoint 阶段。关键设定来自 perf/throughput/README.md单表test_table(id INTEGER PRIMARY KEY, data TEXT)每个事务插入BATCH_SIZE行默认 100id 来自所有连接共享的计数器事务之间不触碰同一行竞争只发生在引擎自身写入路径上两个引擎都运行PRAGMA synchronous FULL每次 commit 都以 fsync 结束SQLite 侧使用 WAL 模式、每连接一个线程通过rusqlite和BEGIN IMMEDIATETurso 侧使用 MVCCPRAGMA journal_mode mvcc、每连接一个独立 tokio runtime、BEGIN CONCURRENTLinux 上使用 io_uring 后端写连接的 auto-checkpoint 关闭由独立连接每CHECKPOINTER毫秒默认 1000执行一次PRAGMA wal_checkpoint(PASSIVE)与服务器实际行为一致。每笔事务的 begin、work、commit 耗时都会被记录重启restarted次数计入其服务时间。准备条件README 列出的环境要求Rust 工具链脚本通过cargo build --release -p txn-throughput构建测试框架uv用于绘制结果图Linux供 Turso 的 io_uring 后端使用可sudo的账号每轮运行前脚本会执行sudo fstrim和echo 3 | sudo tee /proc/sys/vm/drop_caches。最后一条有实际副作用fstrim会向数据库所在挂载点的磁盘发出 TRIM 命令drop_caches会丢弃系统 page cache。文档说明这样做的目的是让消费者级 SSD 在空闲期排空写缓存、避免后一轮继承前一轮的写积压如果你不希望修改磁盘状态或没有 root 权限这一步无法省略也就不能直接跑完整的run.sh流程可改为直接运行单次 harness见下文可选直接运行单次 harness。txn-throughput是 cargo workspace 的成员见根 Cargo.toml 中perf/throughput所以在仓库根目录下即可完成构建。另外 scripts/bench.sh 通过git rev-parse --show-toplevel定位仓库根目录需要在 git 检出中运行。快速试跑缩短参数验证流程完整基准耗时很长先用文档给出的缩短配置跑一遍确认工具链、sudo 和输出路径都正常CONNS1 8 64 REPEATS2 DURATION10 IDLE5 ./scripts/run.sh命令在perf/throughput目录下执行。含义只在 1、8、64 三个连接数上各跑 2 次每次只测量 10 秒默认 30 秒fstrim后只空闲 5 秒默认 30 秒。环境变量由 scripts/bench.sh 读取run.sh调用它因此两个入口都接受这些变量。完整基准./scripts/run.sh不带任何变量会在 1、2、4、8、16、32、64 个连接上各跑 3 次并绘图。README 估计耗时约一小时其中一半是每轮运行前 30 秒的磁盘空闲等待而 scripts/run.sh 的注释写的是约两小时。两处口径不一致按较保守的估计预留时间即可。可选直接运行单次 harness如果想跑单个引擎、单个连接数的配置而不走脚本先构建再直接调用二进制。scripts/bench.sh 展示的构建和调用方式为cargo build --release -p txn-throughput二进制默认位于 cargo target 的release目录脚本通过仓库自带的scripts/cargo-target-dir查询实际位置尊重CARGO_TARGET_DIR。参数与 bench.sh 中一致cargo run --release -p txn-throughput -- \ --engine turso --connections 16 \ --batch-size 100 --checkpointer 1000 \ --duration 30 --warmup 3 --run 1 \ --db-dir ./db --out-dir ./plot--engine取sqlite或turso。--db-dir存放数据库文件--out-dir存放结果文件每次运行会写入自己的文件拒绝覆盖已存在的文件拒绝时提示already exists; remove it or pass another --db-dir/--out-dir。txn-throughput --help列出了全部选项其中与对比相关的两个--mode immediate让 Turso 以 WAL BEGIN IMMEDIATE运行与 SQLite 相同的单写者路径SQLite 只支持immediate模式--io syscall切换 Turso 的 IO 后端Linux 上默认io_uring非 Linux 默认syscall见 main.rs 中的DEFAULT_IO。如何读到每秒事务数一次完整运行结束后TPS 出现在三处终端与plot/bench.log每轮运行打印摘要形如{引擎} transactions, {行数} rows in {秒} s: {transactions/s}, {rows/s}随后是服务时间分位数p50/p99/p99.9/max、CPUuser、sys、占一个核心的百分比、占全部硬件线程的百分比、每事务微秒数、磁盘写入统计和 checkpoint 的 p50/max 耗时。bench.log开头还记录机器型号、硬件线程数、内核版本和磁盘信息方便复现时对照环境plot/engine-cconnections-rrun-result.csv每轮一行包含transactions_per_s、rows_per_s、cpu_us_per_transaction、restarts、各分位数、磁盘写入量与 checkpoint 统计plot/throughput.png及.pdf、.tikz左轴是 TPS 随连接数的变化右轴0–100%是进程 CPU 占全部硬件线程的份额每个点是各次运行的均值并带一个标准差的误差棒。run.sh在跑完全部配置后用uv run plot/plot-throughput.py自动生成这三份图。另外每轮还会写三个明细 CSV...-rrun.csv记录每个事务的开始时刻、是否预热、重启次数和 begin/work/commit 耗时...-timeline.csv按秒记录每秒提交的事务数和 CPU 占用...-checkpoints.csv记录每次 checkpoint 的开始时刻与耗时。所有数据库文件保留在db/timestamp/下脚本不会删除任何历史文件。结果可信度如何判断harness 自带一次正确性校验运行结束后通过一条全新连接对表做SELECT count(*)行数必须等于已提交事务数乘以BATCH_SIZE不一致时打印the table holds N rows but M transactions of B rows committed并以退出码 1 结束见 main.rs。所以一次运行跑完且退出码为 0本身就包含了落盘数据完整性的检查bench.sh也把每一轮 harness 的退出状态单独取出非 0 即整体终止。解读结果时的两个文档提示每轮都从一个全新的空数据库文件开始测量 30 秒前有 3 秒预热预热期的事务会被记录但标记为 warmup不参与汇总和绘图奇数次重复按连接数从小到大扫描偶数次从大到小顺序效应会体现为两者的差异——对比结果时应成对看而不是只取某一次。限制与不适用情况该流程要求能执行sudo fstrim与清空 page cache缺少相应权限时不能按文档路径复现完整基准磁盘统计来自/proc/diskstats仅在 Linux 上可用输出目录中若已有同名结果文件运行会拒绝覆盖而不是静默替换重跑时换OUT/DB_DIR或先移走旧文件仓库本身只读约束下在自有检出中操作。如果只需要单次配置的 TPS 而非完整对比曲线直接用上文单次 harness的路径需要 SQLite 与 Turso 全连接数扫描加绘图时主路径就是./scripts/run.sh。【免费下载链接】tursoA SQL database in Rust: SQLite-compatible, now also speaking Postgres (experimental). The LLVM of databases.项目地址: https://gitcode.com/GitHub_Trending/tu/turso创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考