压测难,难于上青天,80%的直播应用都败在了这里

目前腾讯WeTest服务器性能测试已经正式对外开放,点击链接:http://wetest.qq.com/gaps/立即体验!

作者:Oliver,腾讯服务器性能测试团队产品经理。 
商业转载请联系腾讯WeTest获得授权,非商业转载请注明出处。

WeTest导读

直播的火爆带来了海量的用户,也带来了海量的服务器并发。本文分析了目前直播行业存在的难点,从腾讯目前的新直播产品——NOW直播出发, 了解直播应用背后的那些事。

直播,突然成为了中国互联网的一个最流行的词汇。在《2016-2020年中国网络直播行业深度调研及投资前景预测报告》中的数据表示,2015年,全国在线直播平台数量接近200家,其中网络直播的市场规模约为90亿,网络直播平台用户数量已经达到2亿,大型直播平台每日高峰时段同时在线人数接近400万,同时直播的房间数量超过3000个,更可怕的是,这一数据还在以极快的速度向上攀升。

直播平台用户数量2亿是什么概念?2016版的《微信数据化报告》中提到,目前微信用户达到了6.97亿人,也就是说,在你身边同龄的3-4个朋友之中,很有可能有一个人是网络直播的用户。

直播火没火,看用户就知道,但是直播有没有前景,就要看科技巨头们对它的态度了。

国外的Facebook推出的Facebook live给其用户带来的全新的体验,不仅增加了用户粘性,还给Facebook带来了新的收入来源。而YouTube live与电视点播相结合的经营模式也给用户带来了新的视频体验。

国内方面,斗鱼、虎牙、熊猫、龙珠、奇秀、花椒等专业的直播平台如雨后春笋般出现。阿里、百度、腾讯等巨头也不甘人后,纷纷推出了自己的直播平台。而直播所涉及的行业领域也从电竞、社交、电商等各个行业间开始广泛出现。

直播下的服务器压力

如此大的用户体量下,直播类的应用对于服务器的要求要高过一般的应用,我们来看看直播类的应用对服务器有哪些更多的挑战?

1、更大的数据量

视频数据和文本数据完全是两个量级的概念,假设一个直播房间有5000人,视频1s的数据60K,那么就需要5000*60=300000KB=292.97MB,基本已经达到了2-3三个手游的大小了,而这只是一个房间产生的流量。今年4月刘涛入驻直播领域,创造了同时在线人数17万,总收看人数71万的数据,如果按照这个数量,服务器就会产生9.73Gbps的带宽,而当前某著名网络直播APP日活跃用户超过了800W,服务器将承受458Gbps的带宽压力。

2、更高的并发量

不同于普通应用和游戏,直播类应用的使用时间段非常的集中,一般来说,社交类的直播app时间集中在晚饭后时间至睡前20点~23点,游戏类App活跃时间集中在下班后18~20点间,秀场类App集中在13点和18(午休及下班时间),因此在这短短几小时之间,会涌入大量的用户,一次大V的直播通常就会造成百万级的用户登录,APP需要有详尽的限流、分流和负载均衡策略,保证服务器不会被冲垮。 
 
(数据来源:大数据解析网络直播市场到底有多火, 
http://mt.sohu.com/20160716/n459532686.shtml

3、更真实的用户登录场景

直播应用与普通应用相比,交互的功能异常多,除了直播视频流的服务器压力之外,还要包括用户消息推送、聊天、礼物、支付以及统计系统带来的数据交互压力,服务器进行需要识别不同的业务字段,才能精确判定用户的行为是否成功完成,从交互频率的角度上来说,直播类的应用,与其说更像应用,不如说更像游戏。

4、更低的延迟

直播需要一个很强的即时性,如果主播的行为和用户的评论无法同步的时候,会给用户非常不好的体验,如果一个用户发现其他用户在欢呼鼓掌,但是屏幕中的主播什么动静都没有的时候,这个直播应用基本可以不要再用了,因此直播类应用不仅需要面对更大的数据量和更高的并发,还要保证更低的延迟。通常可以要保证服务器的处理数据速度要快,要有足够强大的带宽;另外则是通过P2P算法保证数据分享的合理性,保证服务器的数据和P2P的数据可以达到平衡。

直播前的服务器准备

直播应用下的服务器成本,与将要承受的流量情况息息相关,不同的直播应用,交互的频度、深度不同,就会产生不同的带宽压力。我们一起来算一笔帐,为直播应用准备服务器,大概需要多少钱?

首先,我们要买一个服务器。买多大的服务器呢?服务器的带宽要满足直播应用的带宽需求,在这里,科普一下带宽是怎么看的: 
带宽通常使用的单位是bps(bits per second),8 bits通常等于1Byte,100Mbps在换算成我们熟悉的文件大小的时候,要除以8,也就是在100Mbps的带宽下,每秒钟可以下载12.5MB的文件,那么一般来说,直播应用需要多少带宽呢?见下图:
 
直播应用一般使用的分辨率是360p,720p以及1080p三种,为了看得清晰一些,一般人们都会选择720p,那么在720p的清晰度下,直播应用需要1024kbps的带宽,也就是每秒传递的数据大小为1024/8=128KB。简单来说,如果在APP中打开直播,使用了720p的分辨率,一个用户每秒钟需要传输128KB的数据(当然实际情况中直播应用还有消息推送,送礼,支付等行为,直播画面分辨率、压缩比等区别,实际会消耗更多的数据)。

那么,直播类应用现在需要承载多少用户呢? 
以目前最红火的几大直播平台为例,斗鱼 TV 的在线人数可以超过1000 万,战旗 TV 在在线人数约500 万左右,龙珠在线人数约 400 万左右,虎牙在线人数约100万,直播平台的带宽成本通常是带宽峰值月结的形式,如果当月最高同时在线人数是200W,也就是每秒要传输的数据量高达244GB,那么理论上消耗的带宽就是2T左右,一个月的开销就在4000W人民币左右。

对于直播应用来说,服务器最难处理的环节就是视频流量和用户交互等高频率高带宽的场景,用户的行为是难以预测的,经常会出现突发性的暴涨,一般在进行活动的时候,流量可能是平时的几十倍。2016年7月11日,PAPI酱的一次直播带来了超过2000W用户的访问,这对于大多数的直播应用来说,服务器的成本都是难以承担的。这也是为什么越来越多的直播应用开始寻求云服务器的支持,目前的云服务商有腾讯云,阿里云,百度云,金山云等,彼此之间在硬件上的类型差别越来越小。

因此直播应用在上线前需要对多样化的用户操作进行针对性的测试,注册,聊天,礼物,支付等行为都需要进行不同接口的测试,NOW直播就是其中之一。 

直播服务器的测试

测试需求的产生

腾讯NOW直播是腾讯目前发展非常迅速的直播应用,获得了通过QQ直接登录直播界面的入口,可见其受重视程度,而NOW直播在一场线上活动中,需要对活动的所有接口进行压力测试,提前暴露问题并解决,确保活动的顺利实施。为此,NOW直播与腾讯WeTest服务器性能测试进行了合作,对应用的业务后台进行了系统性的测试,对活动进行了一整套场景测试。(对于视频流量、用户交互等高频率高带宽的场景,也同样可以使用WeTest服务器性能测试的的高级模式进行,本文不做展开,尽请期待后续干货。)

测试前的思路梳理

一般来说,对于活动中的功能节点,测试过程中通常关注两点: 
1、 单接口压测,提前暴露核心模块的问题 
2、 多接口架构问题,场景压测尽量模拟真实用户行为,使得压测结果更有说服力 
对于这次活动,NOW直播的思路也同样是通过简单的HTTP单接口和复杂的多接口场景压测,通过压测工具给后台和客户端APP增加压力源,帮助发现问题。

测试的执行

1、单接口压测——步步为营,逐渐迭代

单接口压测的原理很简单,就是不断的对某个功能接口不断加压,直到发现出现问题的那个极限就可以,在腾讯WeTest服务器性能测试上,操作如下: 
1)点击压测产品首页中的快捷入口:HTTP直压。模式选择简单模式,名称和描述可以自己填写。(图中示例起始人数50人,每隔60秒增加50人,加到200人为上限) 

2)新建一个客户端请求,接口压测包括读写接口,读接口基本是GET请求,写接口基本是POST请求。GET请求使用url请求参数,POST请求使用x-www-form-urlencoded方式传递参数,在这里NOW直播方法选择GET,填写想要测试的URL。 

3)编辑一下测试模型,增加一个场景名,单接口测试只测试一个功能接口,因此模式选择“单场景”,压力百分比设置为100%。 
 
通过这样的压测方式,不断增加服务器压力,直到找到瓶颈位置,腾讯WeTest为NOW直播实现了2W/s的并发量,满足了NOW直播的并发需求。

2、多接口压测——真实模拟,定位问题

多接口压测的主要逻辑,就是通过构建不同的功能接口,模拟用户的真实行为,从而帮助开发者定位接口问题。

NOW直播的测试方式是通过GET请求调用一个功能接口,通过这个功能接口随机产生不同行为逻辑的机器人,模拟真实的QQ用户,然后通过POST请求执行具体的业务行为,从而发现功能之间会产生的逻辑问题。

NOW直播测试团队读接口基本是GET请求,写接口基本是POST请求。GET请求使用url请求参数,POST请求使用x-www-form-urlencoded方式传递参数。

(在腾讯WeTest 服务器性能测试上,我们可以进行如下操作:)

1)首先,通过GET请求,读取一个用户的“登陆态”,通过这个功能接口随机产生不同行为逻辑的机器人,模拟真实的QQ用户;然后通过POST请求依次执行具体的业务行为,从而发现功能之间产生的逻辑问题。 

2)在测试场景中输入场景名,NOW直播测试的是“登录-进入房间-点赞”这样三个操作,然后“模式”选择“上下文”,点击“压测场景”,选择调用不同的功能接口。 

目前腾讯WeTest服务器性能测试支持同时接入8个场景,更多的场景可以更真实的模拟用户的行为。

总结

通过NOW直播与腾讯WeTest在服务器性能测试方面的合作可以看出,目前的直播应用非常注重两块的内容:一个是单接口的承载能力,一个是多接口的架构情况,对于开发人员来说,前者的问题是好解决的,通过平行扩容的方式就可以做到优化,但是后者的问题则需要在多个功能接口之间不断定位问题,不断尝试新的压力测试,才能找到那个存在的隐患。 
 
基于NOW直播的需求,腾讯WeTest也提升了可同时调用的场景接口,从原来的4个增加到了8个,之后也会不断的增加;并且也不断的增加可以实现的并发数,为用户提供更大的并发压力和更真实的行为场景,节省了更多的测试成本。 
做好这些,才能做出更好的直播应用。

腾讯WeTest运用了沉淀十多年的内部实践经验总结,通过基于真实业务场景和用户行为进行压力测试,帮助游戏开发者发现服务器端的性能瓶颈,进行针对性的性能调优,降低服务器采购和维护成本,提高用户留存和转化率。

目前腾讯WeTest服务器性能测试已经正式对外开放: 
体验地址:http://wetest.qq.com/gaps/ 
如何使用简单模式:http://wetest.qq.com/help/documentation/10094.html 
如何分析报告:http://wetest.qq.com/help/documentation/10099.html 
常用测试指标:http://wetest.qq.com/help/documentation/10098.html

时间: 2024-08-09 19:49:18

压测难,难于上青天,80%的直播应用都败在了这里的相关文章

一次tomcat压测调优记录

1. 前言 该tomcat web应用承担集团登录注册页面功能,对性能有一定要求,由于先前没有太多相关经验(只压测过一个dubbo服务),这次调得比较艰辛,便做个记录. 2. 调优过程 起初没有给运维任何tomcat配置要求,同时也没留意去确认tomcat配置,这个导致了后续压测过程各种诡异的问题. a.在压测初期,持续请求10分钟左右出现无请求进来,netstat查看的tomcat所在服务器存在大量CLOSE_WAIT的连接. CLOSE_WAIT的连接一般是自己程序中缺少关闭连接等引起,但是

想做iPhoneX抢购活动?压测大师先教你优化网站后台

北京时间9月13日凌晨1点,iPhone 10周年,在Apple Park乔布斯剧院,苹果发布了三款新iPhone.全面屏iPhone X来袭,这款被定义为未来的智能手机黑科技满满:全面屏,无线充电.面部识别"Face ID"以及跟踪你脸部动作的Animoji.和往年的苹果秋季发布会一样,发布会在开始之前就获得了极高的关注,苹果官网也会承受极大的并发压力,看看往年的情况: 2014年的iPhone 6预购的情况:  2014年9月12日下午三点,香港各个公司的办公平台都在不断的刷新苹果

性能压测诡异的Requests/second 响应刺尖问题

最近一段时间都在忙着转java项目最后的冲刺,前期的coding翻代码.debug.fixbug都逐渐收尾,进入上线前的性能压测. 虽然不是大促前的性能压测要求,但是为了安全起见,需要摸个底心里有个数. 毕竟这次转java的服务都是集团核心公共服务(主要是订单域服务).(等我们顺利上线了,我再来好好总结下其中的坎坷和壮举.) 废话不多说了,直接进入主题. 由于这次压测主要重点是关注正向的两个核心订单服务,下单服务.查单服务.查单服务初步压测下来问题不大,主要是db的索引和cache的问题. 下单

后端服务性能压测实践

转自:https://mp.weixin.qq.com/s/XW9geHZ9odHdI7srDiKBIg 目录 背景 环境检测 压力机及压力工具检测 Linux openfiles limit 设置 排查周边依赖 空接口压测检测 聚合报告中 throughput 计算 压测及性能排查方法 关注各纬度 log Linux 常规命令 性能排查两种方式(从上往下.从下往上) 总结 背景 最近大半年内有过两次负责性能压测的一些工作.一件事情做了一次可能还无法总结出一些东西,两次过后还是能发现一些共性问题

(转)后端服务性能压测实践

作者:王清培(Plen wang) 传送门:https://www.cnblogs.com/wangiqngpei557/p/7953453.html ---------------------------------------------------------------------分割线------------------------------------------------------ 入职新公司,没人理我,负责的需求开发一直很忙,要么环境有问题,要么Bug卡住我找开发,回了一句

JMeter在linux上分布式压测步骤(二)

哈喽,我又来了~ 前提:三台linux虚拟机,一台作为master,另外两台作为slave. 一.server端 1.修改1099端口,client和server通信的端口,可以不修改,默认就是1099 2.启动jmeter-server (这里启动的时候可以看到ip后面的端口不是1099,这里不用管,1099是client和server的通信端口,和这个没有关系) 二.client端:配置master和slave 1.进入到jmeter的bin目录下,打开jmeter.properties c

apache ab压测快速使用(天下没有难学的技术,只有LJ的教程)

目录(没有你想要的直接掠过,这里以window为例) 如何下载ab 如何使用ab ab常用参数介绍 ab压测遇到坑看这里 一.如何下载ab 1.从官网下载(http://httpd.apache.org/)流程如下建议到官网下载 第一步 第二步 第三步 第四步 好了到这里,下载就OK了(ab藏在Apache24/bin下面,此工具可以单独抠出来使用,不依赖任何东西) 二.如何使用ab 1. 进入到Apache24/bin下面,你会看到如下场面.   windows + R健打开运行命令框输入CM

基于Locust、Tsung的百万并发秒杀压测案例[转发]

原博客地址http://f.dataguru.cn/article-9116-1.html 不久前,数人云联合清华大学交叉信息研究院 OCP 实验室通过 10 台 OCP 服务器成功承载了百万并发 HTTP 请求. 此次实验设立的目标是在物理资源最小值的情况下完成 100 万并发处理,通过此次实验,最大化验证了基于 Mesos 和 Docker 技术的数人云 DCOS (数据中心操作系统)承载高压的能力. 百万压测工具与硬件 压测工具 本次选择的加压工具是分布式压测工具 Locust + Tsu

真刀真枪压测:基于TCPCopy的仿真压测方案

郑昀 基于刘勤红和石雍志的实践报告 创建于2015/8/13 最后更新于2015/8/19 关键词:压测.TCPCopy.仿真测试.实时拷贝流量 本文档适用人员:技术人员 提纲: 为什么要做仿真测试 TCPCopy是如何工作的 实作:仿真测试的拓扑 实作:操作步骤 可能会遇到的问题 ip_conntrack 少量丢包 离线重放 不提取7层信息 观测的性能指标 0x00,为什么要做仿真测试 线下的传统压力测试,难以模拟真实流量,尤其难以模拟正常流量混杂着各色异常流量.所以,线下压得好好的系统,上线