前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >以体验为中心的性能优化

以体验为中心的性能优化

作者头像
腾讯大讲堂
发布2018-02-11 16:51:31
1K0
发布2018-02-11 16:51:31
举报

首先,这不是一篇讲述关于产品设计与用户体验,而是如何进行产品性能优化的文章。如果你具有一定技术背景,并且对互联网产品性能优化感兴趣,这篇文章将以QQ音乐的性能优化为例,为你提供一套如何进行性能优化的方案作为参考;如果你是一名对通过技术手段提升用户体验感兴趣的产品经理,那么这篇文章除了讲述一些提升用户体验的hao123式的准则外,同时也深入一些技术细节,希望你不至于感到枯燥。

作为一款月活跃用户超过4亿的产品,QQ音乐每天在线听歌次数超过1.4亿次,非在线听歌超过10亿次。在线听歌与下载歌曲是否快速流畅影响着用户的核心体验。在对流媒体性能进行优化之前,QQ音乐在这方面相比国外竞品有不少差距,甚至某些指标落后于国内竞品;经常有一批用户持续地反馈听歌卡,无法听歌,下载速度慢。而在对QQ音乐进行流媒体性能优化之后,核心性能指标大幅领先竞品,而且用户给予了非常正面的反馈。由于优化成效显著,优化项目还获得了腾讯公司级卓越运营奖金奖。

这一转变的背后发生了哪些故事?应该以怎样的态度去对一款互联网产品进行性能优化?QQ音乐给出的答案是: 用户体验为至上,围绕提升用户用户核心体验指标作文章,提出“一篮子”优化策略,灰度部署,A/B测试,动态运营。简言之,就是设定核心体验目标,真实全面准确搜集体验数据,提出“一篮子”优化策略,动态运营的四步框架。

一. 设定技术优化指标与目标: 一切为了用户体验

在一切以用户体验为中心的互联网产品时代,任何开发活动都应该以改善用户体验为终极目标,性能优化也不例外。优化产品技术性能最忌陷入纯粹为了追求技术极限而优化的境地。

一位产品经理前辈曾经精辟地总结过用户体验三准则:“别让我等,别让我想,别让我烦”。交互与视觉设计侧重于“别让我想”和“别让我烦”, 而性能优化则在于解决”别让我等”以及部分”别让我烦”的问题。

因此QQ音乐流媒体性能优化从一开始就定位于解决困扰用户的体验问题。凡是不能改善用户体验的指标就不去优化,凡是能提升用户体验的手段都要发挥到极致。在”两个凡是”的指导思想下,首先要弄清楚用户痛点在哪里。而寻找用户痛点没有捷径,最简单可靠的办法就是去联系用户,获得真实的用户反馈。QQ邮箱在腾讯内部是公认的七星级产品。在打造QQ邮箱的过程中,张小龙曾要求他下面的产品经理每天浏览一千条用户反馈,回复其中的一百条,联系十个真实的反馈用户。在利用“千百十准则”进行了几个月的实践以后,我们提炼出了用户听歌与下载相关的几个核心痛点: 在线听歌开始时需要缓冲等待; 听歌过程中出现卡顿; 听歌发生错误; 下载歌曲速度慢; 歌曲下载不下来。这里既有”别让我等”的诉求,也有”别让我烦”的诉求。

在弄清核心体验指标以后,为了有一个更清晰的优化目标,需要将这些指标按不同的权重相加,计算一个体验得分。原因是在这些体验指标中,某些指标是互相冲突的。以听歌开始之前的缓冲时间与听歌过程中出现卡顿的几率为例: 如果开始播放之前多缓冲一点数据,播放过程中出现卡顿的几率就要低得多。但是这样一来,提升了“别让我烦”的体验,却降低了“别让我等”的体验。

因此在优化项目开始阶段,就需要所有项目干系人,包括开发人员,产品经理和老板都参与进来,对体验指标的优先级进行排序,然后给每个指标赋予不同的权重, 再将权重值与指标的完成度相乘得到每项体验的得分; 然后将每项体验得分相加,就得到了体验总得分。如果体验得分提升,我们可以认为用户的体验是改善了; 否则认为用户的体验变差了。

以QQ音乐为例,我们提取了听歌过程中的卡顿几率,听歌开始前的缓冲等待时长,下载歌曲速度,听歌下载错误率四个体验指标以后,按优先级排序,依次赋予的权重值是40%, 25%, 20%, 15%。指标的优先级可以在产品的不同阶段根据产品策略作不同的调整。比如手机用户为了节省流量,相比PC客户端更倾向于把歌曲下载到本地以后再听。这样对手机用户而言下载速度这个体验指标比在PC上就要更重要一些。

以下是QQ音乐进行技术优化以来,体验得分的变化情况:

二. 真实全面准确地收集用户体验数据

互联网相对于传统软硬件产品的优势在于可以轻而易举获得所有用户的真实而全面的体验指标数据。因为用户的使用场景,网络环境是千变万化的。只有关注用户真实的体验数据,才能知道优化策略是否有成效。

“工欲善其事,必先利其器”。为了监控不同优化策略产生的实际优化效果,我们搭建了一套海量用户数据分析平台,用以搜集每天用户数十亿次的听歌下载数据,进行计算,处理和展现。所有用户的听歌数据被计算成核心体验指标平均值,再进一步计算成核心体验得分。通过监控体验得分的走势,就可以掌控不同优化策略带来的效果。

数据收集需要准确真实而全面。数据只有在达到一定规模的时候,才能对优化产生指导的意义,否则很容易由于数据的波动误导策略的判断。为了准确,最好采用HTTP/TCP协议进行上报,同时制造不同的用户使用场景,对客户端进行抓包分析。为了真实,必须上报用户真实的听歌下载数据,而不是测试或受控环境下的数据。为了全面,上报接入后台服务必须做多运营商和多地域的部署,以最大程度地收集不同用户的数据。

在收集了足够的数据以后,除了生成体验指标总分,还需要有对用户分不同维度的结果对比展示,以便于观察优化策略对于不同维度指标的变化带来的影响。以QQ音乐为例,在生成体验得分曲线之外,我们还以不同CDN,运营商,省份城市,客户端版本,歌曲码率,网络环境等为维度,进行指标与得分的对比展示。

下图为PC客户端数据分运营商展现的效果:

三. 集思广益,从后端到前端的“一篮子”优化策略集

在确立了核心体验指标,并完成了体验得分监控以后,才可以进行优化策略的提出与实施。还是以QQ音乐为例,阐述各种优化策略的优化原则与效果。

1

接入层尽量采用竞速接入

由于互联网产品跨地域与跨运营商的特性,接入层一般要做跨运营商跨地域的分布式部署。这样接入服务器离用户越近,效果就越好。但是由于存在运营商网络地址转换(NAT), 域名劫持,Local DNS错配等问题,根据调度系统分配给用户的接入服务器并非一定是最佳的。这时如果能分配用户多个备选节点,然后在用户侧通过测速,竞争选择最优的接入节点,则往往既能保证用户最大程度选择到最佳接入节点,同时在某个节点发生故障时用户无缝切换到其他无故障节点。

以QQ音乐的流媒体分发CDN为例。CDN的加速原理是通过在最接近用户的地方部署缓存节点,然后用户通过访问这些最近的节点来获取数据。QQ音乐使用三个CDN供应商同时加速流媒体文件分发。然后从用户测同时向三个CDN发起测速请求,选择速度最快的CDN进行访问。

这样做带来的好处是: 1) 同时利用了三个CDN的接入节点,从中挑选最快的节点,让接入点覆盖面最大化最优化; 2)为三个CDN分别计算体验得分并反馈给供应商,让CDN供应商形成竞争关系。供应商为了获取更多业务份额必须最大程度优化性能; 3)在某个CDN由于业务波动影响性能或发生故障时,用户会自动切换到其他CDN供应商,实现无缝切换。

这样我们对调度用户具体访问哪一个接入节点“失控”了,但是带来了动态和智能调度的优势,以及供应商持续优化服务质量的动力。今年在其中一个CDN发生重大事故时,几乎所有依赖该CDN的公司其他业务都受到了重大影响。但是由于竞速接入机制的存在,QQ音乐自动将分配到该CDN的访问无缝调度到其他CDN,实现了故障期间零用户投诉。

以下是使用单一CDN接入与三个CDN竞速接入的效果对比: (3050515为使用了竞速的版本,3050414为使用单一CDN接入的版本)

2

尽量将数据缓存在离用户最近的地方

除了优化网络性能,缓存也是一个提高性能的有效手段。CDN网络就是通过建立城域缓存节点,区域中心缓存节点以及源站节点这样的三级缓存来加速内容传输。缓存节点离用户越近,性能加速效果就越好。因此效果最好的缓存节点是用户的本地磁盘/Flash存储。

由于用户存储空间有限,为了尽量利用用户的本地缓存空间,除了缓存用户最近听过的歌曲并使用最近最少使用法则进行淘汰,我们将更多的空间使用在缓存每首歌曲的首片数据,而不是整首歌曲。这样做的好处是: 1)节省了空间,可以更大规模地缓存热点歌曲在本地 2)在用户听歌时,可以立即从本地获取首片数据并进行播放;然后在播放的时候从网络上请求歌曲的剩余部分,实现一点就听的效果。在实现了这样的缓存策略以后,用户听歌命中首片数据缓存的比例从85%提升到了95%,极大地增加了一点即听的概率,提升了“别让我等”的体验。

3

尽量预测用户的行为并预先获取数据

让用户感觉到有"秒听"“秒传”快感的秘诀在于预先行动。

首先,可以通过预加载下一首歌曲来减少切歌时的停顿时间。大部分用户都是以可以预测的听歌顺序来听歌的。对于顺序播放和单曲循环固然是知道下一首歌的播放序号;即使对于随机播放模式,我们也可以通过事先生成好随机数队列来得到一下首歌的播放序号。这样在当前播放歌曲缓冲完毕之后,我们就开始缓冲下一首歌曲的首片数据。当切换到下一首歌时,用户几乎不会感觉到停顿。

其次,可以预先建立一条到服务器的连接来减少不可预知的切歌带来的重新建立连接时间。如果用户手动切换歌曲,则无法预知下一首歌曲的播放序号。在这种情况下,我们可以预先建立起从客户端到服务器的连接。当用户主动切换其他歌曲时,可以立刻使用这条预先建立好的连接,从而节省建立连接的时间。

再者,尽可能地将用户最可能听的歌曲的首片数据预先拉取到本地进行缓存。由于缓存歌曲首片数据带给了我们存储大量歌曲的能力,我们可以将热门排行榜歌曲,用户的“我喜欢”收藏歌曲,用户自定义的歌单歌曲等用户最常听的歌曲首片数据预先拉取到本地保存。除此之外,在用户浏览歌单页面时,就预先将该页面的歌曲首片数据预取到本地。这样,当用户点击听歌时,将会惊悉地发现这些歌曲可以"秒听"。

4

尽量使用IP方式而不是域名方式访问服务器

互联网服务经常要面临的一个问题是域名解析劫持。中国的运营商由于特殊原因,经常需要自己建立一个缓存服务器,将用户要访问的音乐内容缓存到该服务器上。然后用户在访问QQ音乐域名时,运营商的域名解析服务器将QQ音乐的域名解析到运营商自己建的缓存服务器上。由于这些缓存服务器往往内容不完整而且容易过时,导致服务质量非常的差,甚至导致用户无法正常访问。

为了解决运营商对域名解析的劫持,我们采用了服务器IP下发的方式。具体做法是根据客户端来访的出口IP地址下发最合适的服务器IP列表给用户,然后为用户选择一个最优的IP进行访问。当IP访问失效时重新获取下发IP或者使用备用域名进行访问。

客户端/Web采用IP方式访问服务器除了可以防止域名解析被劫持,还可以节省域名解析的时间,可谓一举多得。

5

尽量根据用户环境提供定制化的参数

不同的用户硬件条件,网络条件,软件环境决定了不同的用户听歌体验。我们可以通过给用户提供定制化的参数来最优化用户的听歌体验。这样的参数可以包括首片数据缓冲大小,歌曲的品质码率等等。比如对于硬件配置高,网络速度快的用户,我们可以尽量减少首次缓冲数据的大小,增加歌曲的码率,从而在不影响听歌流畅度的前提下,减少用户的听歌等待时间,并提升听歌体验;而对于硬件配置差网络速度慢的用户则增加首次缓冲的等待时间,降低歌曲码率,从而尽可能在听歌过程中避免出现卡顿。用户的环境条件可以通过历史数据统计得知。

6

失败时尽量采用不同方式重试来提升成功率

在访问服务器时如果能采取独立的方式进行重试,则每重试一次可以将成功率提升一个数量级。在重试的时候可以采取更换接入域名/IP,端口等方式,也可以降低内容的品质,或者尝试使用不同的程序组件,走备用的设备,通道等等。通过不同方式的尝试,可以将服务失败的概率降到最低。当然,重试策略也要考虑控制频率,以免引起服务雪崩。

其他优化策略包括增加TCP滑动窗口的大小,从而减少TCP慢启动的时间;服务器侧可以在丢包率较高时对同一个包发送两次来降低丢包率等。

四. 灰度发布,A/B测试,动态运营,达到最优优化效果

在提出了从后端到前端的技术优化策略集以后,需要对不同的策略进行逐步实施。为了减少策略实施带来的风险,以及甄别不同策略带来的优化效果,需要对不同策略进行灰度部署。比如在某个区域的某个运营商,选定一半用户采用某种策略,另一半用户不采用该策略,然后对比体验得分的结果。如果有效果,然后再逐步扩展到其他区域和其他运营商,再观察对比效果。通过这样的方式,可以得知某种策略带来的效果与副作用,并可以及时发现部署策略带来的问题。

动态运营的另一个意义,在于在优化过程中,持续联系用户,获取反馈,从而获得新的优化策略的灵感。在我们的优化过程中,有许多优秀的策略就是在与用户交流的过程中提出的。

五.结论

技术优化需要以提升用户体验为目标,否则很容易陷入为了显示技术实力而作出效果不显著的优化的困境,既浪费了资源,又打击了士气。经过我们的实践发现,以设定核心体验目标,真实全面准确搜集体验数据,提出一揽子优化策略,动态运营的四步框架,可以将优化资源集中于提升用户体验之上,从而最大程度解决”让用户等”,”让用户烦”的问题。

版权声明:转载请注明出自腾讯大讲堂,请勿摘录并用于商业用途发布。

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2015-01-04,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 腾讯大讲堂 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 一. 设定技术优化指标与目标: 一切为了用户体验
  • 二. 真实全面准确地收集用户体验数据
  • 三. 集思广益,从后端到前端的“一篮子”优化策略集
  • 四. 灰度发布,A/B测试,动态运营,达到最优优化效果
  • 五.结论
相关产品与服务
内容分发网络 CDN
内容分发网络(Content Delivery Network,CDN)通过将站点内容发布至遍布全球的海量加速节点,使其用户可就近获取所需内容,避免因网络拥堵、跨运营商、跨地域、跨境等因素带来的网络不稳定、访问延迟高等问题,有效提升下载速度、降低响应时间,提供流畅的用户体验。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档