“无处不在的性能”优化您的流媒体解决方案的最终QoE
是什么严重损害了这家此前保持不败的流媒体服务的声誉?
视频流解决方案的每一项新功能都为舒适的观看过程和与应用程序互动的纯粹乐趣增加了分数.
但为什么流失率高于平均水平? 尽管有一系列可用的个性化功能和所有观众只能梦想的UI体验, 一家流媒体服务提供商的用户正在逐渐流失. 什么成了问题的根源?
一家人每天聚在一起看电视剧. 大家都迫不及待地想知道下一集会发生什么, 但恰恰是在紧张的戏剧场面中, 视频播放器最后会死机.
就在这个时候，一群朋友连想看的电影都没能打开. 尽管它很快就被放在了图书馆藏书的最上面, 单击预览后出现意外错误.
除了那个被毁了的夜晚，是什么把这两个人联系在一起的呢? 他们都成为了他们最喜欢的流媒体服务性能问题的受害者.
关于应用性能最棘手的部分是你的容错余地很低, 哪怕是一个错误, 如果不按时固定, 可能会导致流媒体服务用户的流失. 当尝试跨多个设备访问用户时，这项任务变得更具挑战性, 因为你打算覆盖的人越多，你的受众就会越广, 可能会出现更多的性能隐患, 通用的和平台特定的.
在性能问题给最终用户造成损失之前，发现并消除它们, 首先应该仔细检查主要的性能漏洞和瓶颈.
让我们一步一步地回顾一下关键性能任务的清单，并提供一些解释，使其更加生动.
单击图像以查看其全尺寸
性能基准测试需要探索的领域
从一开始, 性能工程团队要么从客户那里获得响应时间kpi的列表，要么根据他们的专业知识生成预期的数字. 这就是客户和团队之间偶尔讨论度量选择的地方——在进行所有检查时依赖准确的参数.
步骤1. 测量相互作用定时
下一阶段是跟踪用户操作的端到端时间——从后端响应时间(到第一个字节的时间或TTFB)到带有资产的网格的加载时间——以指示和优先考虑性能问题, 如果有任何.
每个用户操作都需要根据需要覆盖的每个客户端设备的既定最佳实践来衡量, 包括网络, 移动, 智能电视, 还有机顶盒, -第75个百分位值. 例如, 在做了四次测量之后, 我们引用与收到的4个值中的3个值的结果相匹配的数字.
75th 百分位测量(点击图片查看完整尺寸)
在某些情况下, 比如开始播放动作, 为了获得真实的图像，可能需要额外的深入分析, 因此，我们可以产生8个或更多的测量值.
回顾一下:将最大值或平均值作为性能优化的起点是不正确的. 度量的终点和预期的计时kpi应该是什么? 通常，我们会与客户分享我们的愿景，这样我们就可以就建议的标准达成一致.
步骤2. 检查内存消耗情况
最赚钱的百家乐软件决定了它的微妙用法, 尤其是在智能电视或安卓机顶盒等平台上，它们有着严格的限制. 如果内存被过度使用，流冻结不会让你等待很长时间.
内存检查结果(点击图片查看完整尺寸)
当我们讨论内存优化时, 先进的技术到位，计数以兆为单位. 所有这一切都是因为我们没有机会升级硬件，以防特定的电视和机顶盒型号, 是什么让节省mb内存成为一项真正的成就.
“缓存有助于提高应用程序性能”被认为是最广泛的性能最佳实践之一. 不过，客户机设备是规则的一个例外. 向电视或机顶盒客户端提供缓存可能会产生相反的效果, 影响内存并导致应用程序延迟问题.
在这种情况下, 从后端获取数据并只存储相对数据集很方便:应用程序获取尽可能多的对象，以避免未使用或很少使用的数据带来过多的内存压力.
步骤3. 检测各种用例的内存泄漏
最重要的是分析内存潜力并制定跨多个设备优化的可能方法, 性能团队密切关注由于内存分配管理不正确而导致的内存泄漏, 以及它们发生的原因.
需要仔细研究并确保目标设备内存足够用于它们的一些场景是活动EPG交互, 活动应用程序页面切换或网格滚动, 持续使用应用程序, 如果可能的话，从12小时到24小时不等.
查找内存泄漏是一件麻烦的事情，有时甚至需要12个多小时. 对于这种具有挑战性的搜索操作，夜间测试可能是一个很好的出路. 启用不间断电视或机顶盒功能，从而跟踪潜在的慢速.
步骤4. 从内容方面检查应用的可扩展性
巨大的数据量会产生许多可伸缩性问题, 这可能会导致应用的响应性受限甚至崩溃. 这就需要对内容集合进行单独的测试, 因为轻松处理100个元素并不意味着类别中的1000个元素不会影响应用的性能.
但哪里可以找到大量的测试数据来执行批量测试，并确保应用程序处理数据而不会崩溃? 在可伸缩性检查期间，查找大数据量成为主要挑战.
进行准确的性能测试, 我们可以通过利用后端生产数据(如果系统已经运行了一段时间)或者在发布到来时生成合成测试数据来填补这个空白.
可伸缩性检查(点击图片查看完整尺寸)
流媒体服务的最终观看体验是否只存在于应用程序层面?
如果我们与视频流服务的其他组件隔离开来, 前端增强的故事将会更快更流畅. 但在现实世界中，所有的依赖和限制都可能影响前端应用的性能.
警告, 预先准备:下面列出了一些隐含的陷阱，以及一些通过前端技术避免它们的生活技巧.
不仅仅是前端
第三方库, 外部插件, 视频播放器, 即使是支持视频流服务的平台也可能是性能问题的根源. 当技术专家无法访问这些代码时，问题就出现了. 在这种情况下，您如何克服性能挑战?
如果你的团队找不到根本原因, 依靠整体的观点来看待一个问题是解决问题的最好方法. 负责链中所有环节的团队之间的沟通, 包括后端, 应用程序, 集成层, 球员是至关重要的.
当交叉沟通很复杂时, 你要做的就是尽你最大的努力使你完全控制的那部分的表现合理化.
CDN响应时间(点击图片查看完整尺寸)
设备异构性需要多步骤性能优化方法
在执行范围规划期间, 应该解决构成视频流产品一部分的每个平台的特定需求. Tizen网络OS, tvo, 安卓 和 安卓电视, iOS, Roku电视 -都有版本，这需要不同的内存和硬件特性. 在进行计时测量时, 由于优化技术很可能不同，计算对于每个平台来说都是必不可少的.
当你处理一堆设备时, 就像许多媒体和娱乐客户一样, 并打算在包括电视在内的十几个平台上推出这款应用, 网络, 移动, 还有机顶盒, 准备好改变发行日历上的日期. 为了尽量减少延误，我们建议一步一步地解开缠结. 首先，以独立层优化为中心. 接下来是特定平台的优化活动.
操作系统和硬件让我们难以前进:对目标设备进行深入研究
如上所述, 越来越多的平台正在进入流媒体服务生态系统, 它们对性能工程师施加的约束越多. 因此, 必须对客户的业务需求进行深入的功能测试，以验证应用的顺利发布及其在所有设备上的可用性. 这将有助于揭示信任他们提供优质服务是多么合理.
在优化前端之前，一个好的做法是调查每个设备版本是否符合计划的应用功能和对其流畅运行的期望, 然后生成一个性能推荐列表.
请注意，就性能测试过程而言, 硬件模拟器不能保证准确的结果, 从而损害了它们的价值. 如果需要测试的话, 假设, 几代网络OS, 每个版本都需要一个物理设备, 因为大部分的性能问题都是与设备相关的.
亚历山大Skamarokha是性能优化团队的负责人 Oxagile.
相关文章
许多品牌都有自己的YouTube频道，但对这个平台所能做的事情几乎一无所知. 这里有一个逐步优化企业YouTube帐户的指南.
2019年9月6日
随着Brightcove和其他公司证明了更全面的方法的价值，按标题编码的做法即将过时. 流媒体的Jan Ozer在NAB 2019上采访了Brightcove的Yuriy Reznic.
4月26日2019
再见，按标题编码. 现在有一种新系统叫做情景感知编码. 了解哪些公司在NAB上发布了CAE解决方案，以及其他流媒体突破.
4月15日2019