一次直播卡顿问题排查处理记录

问题来了: 收到用户反馈观看直播卡顿

一、直播数据流

推流端(发布端)---自建流媒体/CDN---拉流端(观看端)
出现卡顿,三个端都有出问题的可能

二、卡顿现象:

画面明显感觉到不流畅,偶尔一个画面卡住1~3秒或卡住一会才会继续播放

三、排查思路:

推流端(发布端)

网络质量(上行带宽)
硬件性能

自建流媒体/CDN

网络质量(上下行带宽)
硬件性能

拉流端(观看端)

网络质量(下行带宽)
硬件性能

模拟推拉流测试

四、排查过程:

因为无法远程发布端电脑,所以我先从服务器开始排查的。

1. 排查服务器端

1.1 服务器硬件性能

首先登陆直播服务器,查看系统硬件资源使用情况
cpu:  top
内存: free -h
带宽:  dstat
磁盘io: iotop, iostat
CPU,内存使用率不高,磁盘io也没有出现排队,出入带宽也不大,在10Mb左右

排除服务器硬件性能问题

1.2 服务器网络

1.2.1 iperf测试
准备一台测试服务器,安装好iperf
①. 流媒体服务器当server,测试服务器当client
②. 流媒体当client,测试服务器当server
上下行带宽在100Mb以上
1.2.2 wget
wget下载一个大的文件,查看下载速度
每秒在6~8MB/s
1.2.3 停掉流媒体程序,iperf监听在流媒体端口,排除端口限速
iperf -s -p 1935
iperf -c ip -p 1935

排除服务器网络不足问题

2. 排查播放端

2.1 用vlc播放流地址,查看卡顿现象

查看流媒体当前最新的一条流id,用vlc播放,发现卡顿严重

2.2 www.speedtest.cn测试带宽

发现下载带宽在20-30 Mb左右,满足观看直播所需要的带宽

排除观看端网络不足问题

2.3 查看CPU,内存使用率,不高

排除服务器网络不足问题

3. 模拟推拉流测试

3.1 使用ffmpeg推流

fmpeg -re -i 02.flv -vcodec copy -acodec copy -f flv -y rtmp://ip:1935/live/789

3.2 OBS推流

用以上两种方式推流时,用vlc测试播放,发现有卡顿现象,再次确认跟网络,硬件性能无关

再次查看流媒体日志(看日志不仔细,第一次看日志只关注了ERROR相关,漏掉了其他信息)

再次查看日志的时候,发现status: data not enough, fps: need(32,30) recv(10,11), rate:3775, speed:980错误,收到的数据不足
查看流媒体服务版本,是老版本,进行升级
升级完程序版本后,再进行测试推拉流,发现观看流畅,没有明显卡顿。
日志中也没有看到data not enough错误

参考链接
https://www.cnblogs.com/qiniu/p/6773045.html

### Vue 中 `import` 导致的性能问题 在大型 Vue 项目中,一次性导入多个模块可能会导致页面加载缓慢甚至卡顿。这种现象通常发生在应用启动时或首次渲染复杂组件时。当使用同步导入方式时,所有依赖项都会被立即解析并加入到打包文件中,这增加了初始加载时间。 #### 使用异步组件减少初次加载负担 为了缓解这一情况,推荐采用按需加载的方式引入组件。通过定义异步组件可以有效降低首屏加载资源量,提高用户体验: ```javascript // 定义基础异步组件 const AsyncComponent = defineAsyncComponent(() => import('./MyComponent.vue')); ``` 这种方式下,只有当组件真正需要呈现给用户的时候才会触发对应的 JavaScript 文件下载请求[^5]。 #### 组合懒加载与路由配置 对于基于单页应用程序(SPA)架构的应用来说,还可以进一步结合路由器实现更细粒度上的延迟加载机制: ```javascript const routes = [ { path: '/', name: 'Home', component: () => import(/* webpackChunkName: "home" */ './views/Home.vue') }, ]; ``` 上述代码片段展示了如何利用 Webpack 的魔法注释来命名拆分出来的 chunk 文件,便于后续优化和调试工作。 #### 静态内容只渲染一次 针对那些不会频繁变化的内容区块,可以通过 `v-once` 指令告知框架只需对其进行一次性的 DOM 更新处理即可。这样做的好处是可以节省不必要的重绘/回流次数,从而提升整体效率[^1]: ```html <div v-once> <!-- 这里的 HTML 只会被渲染一次 --> </div> ``` #### 动画场景下的注意事项 如果存在复杂的交互逻辑涉及到大量的 getter/setter 访问,则应当特别留意这些操作所带来的潜在负面影响。尤其是在执行连续帧更新的任务期间(比如 CSS 转场效果),过度读写属性可能导致 CPU 占用率飙升。因此建议开发者们尽量简化此类场合中的计算过程,并考虑缓存中间结果以减轻压力[^2]。 ### 实际案例分享 在一个实际项目里遇到了由于大量数据渲染造成的内存泄漏以及滚动条不流畅等问题。经过深入排查发现主要原因是每次新增一条记录都要重新构建整个列表树形结构。最终解决方案是借助虚拟化技术仅保留可见区域内的节点实例,极大改善了响应速度的同时也减少了垃圾回收频率[^4].
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值