1节课带你零基础学习Android Monkey,10年测试老兵让你从懵逼到吊炸天,直播时间:3月31日19:30-20:30 加QQ:3311351622获取免费直播报名资格(PS:老师是国内某知名大型互联网公司的测试大佬,嘘,低调)

“官宣”下新浪微博崩溃的架构测试

上一篇 / 下一篇  2018-10-19 09:48:35 / 个人分类:软件测试


   
  如果说昨天什么最火,估计就是“官宣”了吧,赵丽颖结婚据说某新浪微博甚至还瘫痪了一阵子。
  传说上次有人说微博内部调整,现在已经支持八个明星同时出轨并发,那么昨天的事情还真是叫人尴尬。
   
  吐槽新浪
  并发对于开发初学者可能觉得没什么确实感觉,毕竟自己做ORM单应用项目的时候遇到的并发量就是自己,撑死了也就是十几个人的并发数。所以很多初学者对于并发崩溃并没有个概念,所以今天我们就来讨论一下各个架构可以承受的并发量是多少。
  目前比较常用的架构包括但不限于ORM,MVC,RPC,SOA等和架构详情,如下图
  
  单一应用架构:将所有功能都部署在一起减少成本和节点,这样的框架适合流量较小的网站,只需要一个应用,而简化数据库访问的增删改查是关键。
  缺点:不方便维护,代码分层不明显,代码越多越难维护,开发的时候我和上帝知道,现在估计只有上帝知道了。
  垂直应用架构:将应用拆成互不相干的几个应用,这样可以承受的并发有所增加,而加速前端页面开发的Web框架是关键。(这里涉及到两个面:一个是将应用按照功能模块拆分并独立部署,另外一个是代码结构上的分层,以SSM为例,分为视图层、action层、service层、dao层,各层之间通过接口之间耦合起来,jsp调用action,action调用service,service调用dao)
  缺点:代码难以复用,独立的模块相当于一个独立的应用。
  分布式服务架构:当垂直应用越来越多,这个时候我们管理起来很麻烦,不仅如此应用间复杂的交互更会让我们手足无措,这个时候我们可以考虑将核心模块抽取出来作为服务中心,让前端应用快速响应市场需求,这个时候,用来提高业务复用和整合应用的分布式框架(RPC)是关键。
  缺点:实际开发中发现有点难,其次网络存在问题的时候远程调用可能较慢,增加服务器资源当并发量降低之后容易造成资源浪费,但相对于dubbo曾经扛起了阿里巴巴帝国就已经可以看出多强悍了,不过还是上一张图对比常用的RPC框架
  
  流动计算架构:当服务越来越多,容量的评估,小服务资源的浪费等问题逐渐显现,此时需增加一个调度中心基于访问压力实时管理集群容量,提高集群利用率。此时,用于提高机器利用率的资源调度和治理中心(SOA)是关键。
  下图是新浪核心业务图,我们有理由相信新浪使用的是流动计算架构这个我不太确定,请大神纠正。
  
  好,罗列清楚,有概念了我们就做简单的并发测试
  贴一下Python的selenium代码:
  #-*-coding:utf-8-*-
  importrequests
  importthreading
  importtime
  classpostrequests():
  def__init__(self):
  self.url='请求的url'
  defpost(self):
  try:
  r=requests.post(self.url,files=self.files)
  print(r.text)
  exceptExceptionase:
  print(e)
  deflogin():
  login=postrequests()
  returnlogin.post()
  #if__name__=='__main__':
  #login()
  try:
  i=0
  #这里是线程数
  tasks_number=150
  print('测试启动')
  time1=time.clock()
  whilei<tasks_number:
  t=threading.Thread(target=login)
  t.start()
  i+=1
  time2=time.clock()
  times=time2-time1
  print(times/tasks_number)
  exceptExceptionase:
  print(e)
  以下是框架并发测试过程和内容
  测试对象:单应用
  使用技术:JAVA的TestNg和Python的selenium
  测试对象搭建:首先是单应用,简单的sql查询,开发一个简单的API接口,代码不贴。
  首先使用7个线程同时执行7个请求,请求时间超过7秒就算测试失败,代码如下:
  @Test(threadPoolSize=7,invocationCount=7,timeOut=7000)
  结果:通过没有报错没有超时。
  把所有参数翻了一番之后
  @Test(threadPoolSize=14,invocationCount=14,timeOut=7000)
  结果:开始出现异常,请求时间出现测试失败的。
  测试对象:SSM
  使用技术:JAVA的TestNg和Python的selenium
  测试对象搭建:MVC,简单的sql查询,简单的API接口,代码不贴。
  首先使用14个线程执行14次,请求时间超过5秒就算测试失败,代码如下:
  @Test(threadPoolSize=14,invocationCount=14,timeOut=5000)
  结果:通过没有报错没有超时。
  把所有参数提升
  @Test(threadPoolSize=180,invocationCount=1800,timeOut=5000)
  结果:请求明显变慢,有些测试开始失败超时,但是并没出现异常。
  继续增加参数值
  @Test(threadPoolSize=2000,invocationCount=8000,timeOut=5000)
  结果:请求明显变慢,开始失败超时,并出现异常。
  注:这里有人会说可以使用redis缓存来提高数据库速度,我这里也配置了redis进行测试在@Test(threadPoolSize=2800,invocationCount=28000,timeOut=4000)出现异常和超时请求
  测试对象:dubbo
  使用技术:JAVA的TestNg和Python的selenium
  测试对象搭建:dubbo分布式集群,使用三台服务器做集群分布,权重一致,使用redis缓存+mysql数据库技术。
  首先使用2000个线程执行18000次,请求时间超过4秒就算测试失败,代码如下:
  @Test(threadPoolSize=2000,invocationCount=18000,timeOut=4000)
  结果:执行了很长时间,但是并没出现超时和异常。
  把所有参数翻了一番之后
  @Test(threadPoolSize=4000,invocationCount=24000,timeOut=4000)
  结果:还是没有出现异常,也没有出现超时
  继续提升参数值
  @Test(threadPoolSize=20000,invocationCount=200000,timeOut=4000)
  结果还是没报错
  于是修改策略,并发请求*5台电脑
  @Test(threadPoolSize=40000,invocationCount=200000,timeOut=4000)
  结果:终于出现异常和超时请求,当然这还是三台服务器,相信更多的资源可以有更好的体验。
  备注:由于测试对象的业务逻辑比较简单,当然,如果测试对像业务逻辑复杂可能会出现误差,以大神你们的为准。
  第四个臣妾只能说我做不到,首先增加资源吃力,其次我以为测试用例只需要增加计算器线程数,同时增加并发请求,但是后来发现这样的请求并没办法模拟出那么恐怖的并发量。这个希望技术提升后来继续操作,毕竟对高并发这块兴趣还是蛮大的。今后有可能会继续模拟环境,当然大神也可以补充改正我。
  写这篇文章的感觉大概就是我写了一年多的ssm都不知道他能承受多少并发,但是我对它原理很了解,我相信很多人也是这样,所以我觉得有必要给大家一个实际的参考,让大家更了解自己正在使用的架构。
      
上文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8052),我们将立即处理。
 

 
 
 
 
     
了解更多课程内容及课程安排,可咨询QQ 2852509883 或致电客服 400-821-0951(工作日9:00-17:30)
【看这里】技术交流、拓展人脉、领取福利欢迎加入博为峰网校大课堂>>>


TAG:

 

评分:0

我来说两句

显示全部

:loveliness: :handshake :victory: :funk: :time: :kiss: :call: :hug: :lol :'( :Q :L ;P :$ :P :o :@ :D :( :)

Open Toolbar