首页 > 极客资料 博客日记
主流流媒体的综合性能大 PK ( smart_rtmpd, srs, zlm, nginx rtmp )
2024-09-19 21:00:03极客资料围观21次
简述
随着互联网的发展,音视频行业越来越火,自然而然的流媒体服务器也是百花齐放。市面上也有很多种类的流媒体服务器,让人眼花缭乱。特别是对技术了解不深的朋友,更不知道怎么选择。
其实作为服务器,主要考察的无外乎几个核心指标,只要符合,基本上都是属于比较优秀的流媒体服务器。我简略说一说这些核心特性:
稳定性,性能,资源占用,并发能力,成本,可维护性
其实这些特性又不是独立存在的,相互影响彼此。比如:可维护性。可维护性分为两类,一个开发的可维护性,一个是运营的可维护性。开发的可维护性包括,软件整体架构清晰,模块耦合性低,层次清晰,
这样对于新业务的扩展比较容易,有问题也非常容易排查;这样的架构也为高效,稳定提供了基石;运营的可维护性,对于新业务的展开逻辑比较清晰,错误排查比较方便容易定位,运维人员维护性差的可能需要 3 个人,而维护性好的可以 1 个人搞定,大大节省了人员成本。同时,对硬件资源可以减少使用的台数,大大的节省运维费用。其实每一点都可以长篇累牍的去讲述它的优缺点,但偏离了本文的用意,这里就不一一列举了。
这里主要介绍几款个人感觉不错的流媒体服务器。 smart_rtmpd, nginx rtmp, srs, zlm 。明白人一眼就看出来,这些主要是 C, C++ 语言实现的服务器,没错。就像有的借助小汽车的底盘,有的借助摩托车地盘,
从起点很多别的语言的流媒体服务器就输了。 C, C++ 基本上属于性能最好的语言,性能上 C > C++, 不要和我抬杠说汇编。:)
名字 | 开发语言 |
---|---|
nginx rtmp | C |
smart_rtmpd | C++ |
srs | C++ |
zlm | C++ |
基本情况介绍
smart_rtmpd 服务器
github 地址: https://github.com/superconvert/smart_rtmpd
gitee 地址: https://gitee.com/superconvert/smart_rtmpd
免费软件,支持 rtmp, rtsp, srt 推流,rtmp, rtsp, srt, hls, dash, http-flv, ws-flv, webrtc 拉流;支持 webrtc sfu 功能, 支持 VOD 功能,支持直播和录像; 特点,稳定,高效,简洁,跨平台,解压及运行,支持的操作系统 Windows, Ubuntun, CentOS, Debian, FreeBSD, ARM 64,无第三方依赖,基本上内核 + glibc 就能运行,软件体积非常小,配置相对简单,由于出道比下面三个晚,名气相对没有下面三个大。
nginx rtmp 服务器
github 地址:https://github.com/arut/nginx-rtmp-module
开源软件,由于 nginx rtmp 依托 nginx 底层,所以性能也是相对比较好的,但功能相对于其余三个,相对比较少一点,也是支持跨平台,需要准备第三方库及编译环境,针对不同的操作系统需要不同的环境配置进行编译适配,过多的功能和说明,请参考它们的 README.md
srs 服务器
github 地址:https://github.com/ossrs/srs
开源软件:srs 基于协程技术,对于单进程的能力挖掘相当强悍,单对于多核应用同时对于 webrtc 的功能支持也是比较全面。也是支持跨平台,需要配置对应的编译环境,过多的功能和说明,请参考它们的 README.md
zlm 服务器
github 地址:https://github.com/ZLMediaKit/ZLMediaKit
开源软件:目前是一个庞大的开发框架,不仅提供服务器的一些功能,还提供一些基础组件,对于国产化的相关规范支持的比较全。过多的功能和说明,请参考它们的 README.md
测试环境
测试一般分为三端,推流端,服务器,拉流端,为了保证公平公正合理的情况下,测试过程中,推流端不做任何更改,推流码率固定;拉流端不做任何更改;服务器端依次运行各个流媒体服务器软件,其它软硬件环境均保持不变。同样的硬件,既同样的 CPU, 内存,硬盘,网络。
软件条件说明:
服务器操作系统 Ubuntu 24.04.1 LTS ( 虚拟机 ) , CPU: 2 , Memory: 8G
软件 | 编译器 | 版本或源码分支 | 说明 |
---|---|---|---|
smart_rtmpd | gcc 5.4.0 | 2024.09.16 乌班图多线程版本 | 老的编译器进行编译,新编译器应该性能会更好 |
nginx rtmp | gcc 13.2.0 | 源码分支:2fb11dffaedc5af66b1442b0315c54a4b9da585d | 大家如果想验证测试结果可以自行选择最优分支进行验证 |
srs | gcc 13.2.0 | 源码分支:747831154742e6e4dee9b16f3a29fc6e01904e8c | 大家如果想验证测试结果可以自行选择最优分支进行验证 |
zlm | gcc 13.2.0 | 源码分支:da704ab2f1184c3c87be64fe18c9f413de101d0f | 大家如果想验证测试结果可以自行选择最优分支进行验证 |
推流软件
软件 | 版本 |
---|---|
OBS | 29.0.2 |
ffmpeg.exe | version 4.3.2-2021-02-02-full_build-www.gyan.dev Copyright (c) 2000-2021 the FFmpeg developers |
拉流软件
软件 | 版本 |
---|---|
rtmpstress.exe | 无 |
ffplay.exe | version 4.3.2-2021-02-02-full_build-www.gyan.dev Copyright (c) 2003-2021 the FFmpeg developers |
测试场景及数据
测试分为三个场景,时延测试,拉流测试,推流测试
时延测试
推流 OBS + 浏览器网页截屏 ( 1920x1080, 8192 kb/s )
浏览器:在线秒表网页
测试协议:rtmp 推拉流
拉流 ffplay -fflags nobuffer rtmp://192.168.23.141:1935/live/stream
测试场景: 一路推流一路拉流,主要测试延时
说明 | smart rtmpd | srs | zlm | nginx rtmp |
---|---|---|---|---|
1.117 | 1.506 | 1.635 | 1.334 | |
1.337 | 1.635 | 2.451 | 1.333 | |
1.247 | 1.507 | 2.194 | 1.334 | |
1.246 | 1.504 | 1.721 | 1.291 | |
1.335 | 1.644 | 3.441 | 1.773 | |
1.287 | 1.505 | 1.677 | 1.290 | |
1.258 | 1.460 | 1.635 | 1.291 | |
1.247 | 1.590 | 1.634 | 1.290 | |
1.374 | 1.548 | 1.677 | 1.204 | |
单位秒 | 1.376 | 1.635 | 1.592 | 1.376 |
拉流测试
推流 OBS ( 4096 kb/s )
测试协议:rtmp 推拉流
测试时长:10 分钟
拉流 rtmpstress.exe 一路推 800 路拉,主要系统指标
说明 | smart rtmpd | srs | zlm | nginx rtmp |
---|---|---|---|---|
86% | 88% | 189% | 95.40% | |
123% | 98% | 200% | 97.40% | |
82% | 99% | 143% | 84.30% | |
23% | 53% | OBS 断开,拉流 187 | 94.80% | |
98% | 42% | 35.00% | ||
89% | 6% | 95.50% | ||
97% | 4% | 40.00% | ||
102% | OBS 断开,拉流全部断开 | 94.80% | ||
81% | 26.20% | |||
38% | 95.00% | |||
CPU 随机抽取 10 次 | ||||
内存 | 0.50% | 3.30% | 0.90% | 0.30% |
结论 平均 CPU 占用率 smart_rtmpd 与 nginx rtmp 旗鼓相当,CPU 占用率相对较低,对于内存的占用也是相对较低,推拉流过程相对平稳,无异常,但 nginx rtmp 业务相对于其它三个服务器业务是最简单的,缓存或 IO 都是简化处理的,其次它是纯 C 实现的,语言上对性能的优化占有天然的优势。
压测过程中 srs 和 zlm 推流一段时间,推流端会产生断开现象,拉流端会出现全部断开的现象。
smart_rtmpd 的拉流链接由 800 路降低到 724 路, 而 nginx rtmp 的拉流链接数由 800 路降低到 664 路。
srs 协程模型只能用一个 CPU ,所以理论上 CPU 不会超过 100%
推流测试
说明 | smart rtmpd | srs | zlm | nginx rtmp |
---|---|---|---|---|
CPU | 13.7% ~ 200% | 23.9% ~100% | 97.4% ~ 200% | 52.5% ~93.8% |
内存 | 13.60% | 6.00% | 11.90% | 0.40% |
说明 top 查看网卡中断和服务器进程交替霸榜,CPU 大部分时间占用和 nginx 相差不多,但 CPU 最大值大于 nginx 。推流长时间有部分链接断开 | "协程(单进程,CPU 最大 100%, 推流长时间推流链接大量断开 )" | 推流长时间有部分链接断开 | top 查看网卡和服务器进程交替霸榜,表现相当不错,推流长时间链接没有断开 |
结论: CPU 表现相对优秀的是 nginx rtmp, smart_rtmpd
内存占用 smart_rtmpd 最多,不过缓冲队列是可配置的,没有降低配置降低内存占用,nginx rtmp 的内存占用比较优秀不过 smart_rtmpd, srs, zlm 的业务功能都比 nginx 复杂很多,内存占用过多是理所当然的,nginx 几乎就是做了一个简单解流封流转流的功能,所以系统的占用需求是最小的"
收尾
各位老铁想不想也想测试一下对比一下各个流媒体的性能呢?包括软件的便利性,兼容性,部署成本,维护成本,可维护性做一个全面的对比。欢迎各位老铁拿出您的数据与结论,选出您最喜欢的流媒体服务器。
标签:
相关文章
最新发布
- Nuxt.js 应用中的 prerender:routes 事件钩子详解
- 【问题解决】Tomcat由低于8版本升级到高版本使用Tomcat自带连接池报错无法找到表空间的问题
- 【FAQ】HarmonyOS SDK 闭源开放能力 —Vision Kit
- 六、Spring Boot集成Spring Security之前后分离认证流程最佳方案
- 《JVM第7课》堆区
- .NET 8 高性能跨平台图像处理库 ImageSharp
- 还在为慢速数据传输苦恼?Linux 零拷贝技术来帮你!
- 刚毕业,去做边缘业务,还有救吗?
- 如何避免 HttpClient 丢失请求头:通过 HttpRequestMessage 解决并优化
- 让性能提升56%的Vue3.5响应式重构之“版本计数”