Siberite性能基准测试实战复现70K QPS洪峰测试并与Kestrel、Darner内存占用对比【免费下载链接】siberiteSiberite is a simple, lightweight, leveldb backed message queue written in Go.项目地址: https://gitcode.com/gh_mirrors/si/siberiteSiberite 是一个用 Go 编写的轻量级、基于 LevelDB 的持久化消息队列服务器。本文带你实战复现 Siberite 的性能基准测试从70K QPS 洪峰吞吐量到与经典队列 Kestrel、Darner 的内存占用对比用真实数据回答这个小而美的队列到底能扛多少量。 为什么 Siberite 值得做性能基准测试Siberite 的定位很明确持久化优先所有消息都落在 LevelDB 磁盘存储中存储引擎封装在 queue/queue.go 中队列可以比内存大得多内存极省不管队列里堆了多少消息常驻内存始终很低协议兼容沿用 memcache TCP 文本协议几乎所有 memcached 客户端都能直接用官方兼容客户端清单见 docs/clients.md。对新手来说这类服务最怕平时很稳、一上量就崩。所以官方专门维护了一套完整的基准测试方案原始数据与图表都集中在 docs/benchmarks.md。 测试环境与三套基准测试方案测试环境来自官方基准文档MacBook Pro2.2 GHz Intel Core i7 / 16 GB DDR3 / SSDOS X Yosemite。对比版本为 Kestrel 2.4.8Java-Xmx1024m、Darner 0.2.5RocksDB、Siberite 0.5.1。测试脚本全部位于bench/bench/目录核心是一个 Go 编写的压测客户端 bench.go它模拟多并发连接做 set/get 操作测试脚本测什么洪峰吞吐flood.sh10 个队列在高并发下的原始吞吐量QPS积压吞吐packing.sh队列堆满大消息后性能会不会崩常驻内存mem_rss.sh队列膨胀再收缩后的实际内存占用 洪峰吞吐量测试100 并发冲到 7.4 万 QPS洪峰测试的思路是预先让队列里始终有消息可取然后用 1 ~ 8000 不等的并发连接对 10 个队列疯狂 set/get观察每秒请求数QPS如何随并发变化。结果非常能打队列服务器峰值吞吐峰值出现时的并发数Siberite74,224 QPS100Kestrel62,213 QPS300Darner56,427 QPS50几个值得新手注意的点Siberite 在 100 并发就摸到 7.4 万 QPS 的峰值比 Kestrel 高约 19%三者都遵循并发增加到某个点后吞吐不再涨的规律——这是压测中判断服务瓶颈位置的经典信号在 2000 并发以上的高压区Siberite49,407 QPS明显甩开 Kestrel57,317 → 6000 并发时已跌至 33,423与 Darner。 大消息积压测试队列堆 800 万条后依然平稳第二个测试更贴近生产消息只有 1KB但先把队列堆到最多 838 万条约 8 GB远超内存容量再测此时的读写吞吐。这种场景下绝对速度不重要重要的是不掉链子。积压条数KestrelDarnerSiberite0 条空队列16,27817,38816,08465,536 条16,37613,18913,5078,388,608 条15,11614,75612,316三条曲线都呈先小幅下滑、随后走平的形态说明当消息溢出内存、必须从磁盘读时三款服务器都能维持稳定吞吐。Siberite 的曲线在 26 万条后几乎是一条直线波动最小。64 字节小消息的积压 出队测试脚本 packing_unpacking.sh则考验 LevelDB 面对海量删除操作是否会退化——2.65 亿条消息的极限场景下三者吞吐都稳定在 1.5 万~1.7 万 ops/s 区间Siberite 全程保持在 1.4 万~1.6 万 ops/s没有出现性能悬崖。 内存占用对比Kestrel 的 1/9这才是 Siberite 的主场。内存测试会不断把 1KB 消息灌入队列0 → 52 万条再全部读出用ps采集服务进程的常驻内存RSS。队列规模1KB 消息KestrelDarnerSiberite0 条182 MB2.8 MB3.1 MB65,536 条454 MB45 MB61 MB262,024 条746 MB50 MB86 MB524,048 条820 MB53 MB92 MB结论一目了然Kestrel 的常驻内存随队列规模线性膨胀52 万条消息就吃掉约 820 MB还在逼近 1GB 的 -Xmx 上限Siberite 虽然比 Darner 略高但内存曲线明显更平缓且消息全部持久化在磁盘上队列再大也不会把内存吃爆对新手来说这意味着一台 2GB 的小机器跑 Siberite 处理几十 GB 的积压队列是完全可行的。 如何快速复现这套 Siberite 基准测试想亲手验证数据三步走1️⃣ 克隆仓库并编译服务git clone https://gitcode.com/gh_mirrors/si/siberite cd siberite go build siberite.go mkdir ./data ./siberite -listen localhost:22135 -data ./data2️⃣ 启动压测客户端压测客户端就是bench/bench/下的 bench.go常用参数-port端口、-concurrency并发数、-sets/-gets读写次数、-queues队列数、-item_size消息大小。3️⃣ 直接跑压测命令官方脚本 flood.sh 需要同时部署 Kestrel 和 Darner 才能出完整对比图只测 Siberite 的话直接模拟脚本中的洪峰场景即可cd bench/bench ./bench -port 22135 -sets 10000 -gets 10000 -queues 10 -concurrency 100把-concurrency换成 1、10、100、1000 等值你会亲眼看到吞吐随并发爬升、在 100 并发附近到达峰值的完整曲线。✅ 新手选型速查Siberite 适合谁✅ 队列规模可能远超内存、需要磁盘级持久化 → Siberite 是省心之选✅ 追求低常驻内存想在低配机器上跑队列 → 92 MB 搞定 52 万条消息✅ 已有 memcached 生态客户端不想改协议 → 直接连⚠️ 需要毫秒级超低延迟的纯内存缓存 → 优先考虑 Redis 这类内存型方案⚠️ 需要复杂路由、事务等企业特性 → 考虑 RabbitMQ 这类重量级方案一句话总结在 100 并发下 7.4 万 QPS 的洪峰吞吐、积压 800 万条消息后吞吐平稳、52 万条消息仅占 92 MB 常驻内存——Siberite 用一份完整可复现的基准测试docs/benchmarks.md证明了轻量级持久化消息队列也能打出硬实力。【免费下载链接】siberiteSiberite is a simple, lightweight, leveldb backed message queue written in Go.项目地址: https://gitcode.com/gh_mirrors/si/siberite创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考