00:00
好,那接下来呢,我们就使用解密塔我们编写的这两个功能进行一个压力测试,那在压力测试期间,我们还要监听它们的一些GVM性能指标,比如我们CPU的使用率,内存的占用率,包括它的GC次数等等等等,我们需要分析这些指标,对他们来做出合理的相应的这些优化,那在这个优化之前呢,我们先来考虑上第一个问题,那在来发送请求的时候,比如我们来发送鼓励mail.com,当我们看到这个首页,其实我们从发送请求一开始,请求呢,必须先来经过我们Linux虚拟机的NGX这个中间键,我们NGX呢,把这个请求再来转交给我们后台服务集群的get外网关,这个网关这个中间件,收到请求以后呢,再把它转给我们后台的整个服务集群的,比如商品服务,那商品服务真正处理完功能以后,将返回的数据先交给网关,然后呢,网关再交给恩吉,恩吉斯再。
01:00
返回给我们,所以我们再来真正功能执行之前,我们还经过了两个中间站,那这中间站对我们的性能到底有没有影响,包括影响有多大,我们心里也得有一个数,那好我们再来压测功能之前呢,我们先把这些中间键,我们先来进行一个简单的测试,我们来打开这个解密,我们先来测试我们的NG,好,我先来添加一个线程用户组,我在这呢写一个50,而且我这一块不能调的很大,由于我这个机器啊,既要跑我的这个压力测试软件,还要跑我们的这个服务,还要跑虚拟机,包括我们还要给大家录视频,我这个一旦调到最大,比如调调到200以上。那大家得到这个视频呢,就是一个音化不同步的就没法听了,所以我以后测试我都用50个线程来进行测试,而且呢,我们在测试期间要持续不断的监控它的性能指标,所以呢,我们在这来勾住,永远让它一直测下去,直到我们手动点停止才行,那好我们就通过它来测试一下N几,好,我们先添加一个取样器,我们先来测试N,那如何测试N几?其实呢,只需要给我们这个虚拟机来发送请求,5610,由于我们NS监听我们虚拟机的八零端口,而且我们之前装NS的时候,给它的这个root目录下放了一个首页,所以我们给N80端口发送请求,默认给我们返回首页,所以呢,我们来给他来发请求,我们服务器或者IP地址,我们就来发到这儿,然后呢,端口号是八零访问它的这个根路径,它会给我们返回首页,而且呢,我们来把它的其他这些指标我们都拿来查看结果数,包括我们的。
02:43
这个汇总报告,还有我们这个叫聚合报告,好把这几个指标呢,我们都拿来,我们开始来监控它好来运行,而且呢,我们要运行这个,我们还要进行实时的监控,由于我们这个NX啊,现在默认是装在我们这个虚拟机里边的,所以我们来到我们这个虚拟机来看一下docker PS们NS呢,现在正在运行,那们想要监控它的CPU使用率,内存等等,这怎么监控呢?我们只需要使用一个命令叫docker status啊,这个命令sta。
03:16
好,这个命令里边呢,我们就能看到我们NG的这个CPU的占用率,包括呢,内存的使用量和最大内存能使用多少,那么虚拟机呢,那么之前分配大概有三个G,所以他们合起来最多能使用三个G,现在呢,NGS只使用了1.5MB,内存的使用率这一块呢,也有包括它的net IO,就是我们这个网络的数据传输等等这些统计数据呢,这都有,而且它这是每秒进行动态刷新的,好我们就来监控它,好我们现在来点个yes,我们来保存,并且来启动来运行好。好,那现在压力测试开始,那这个压力测试期间呢,我们来看一下,在我们这个虚拟机里边,我发现N几主要呢,比较浪费CPU,它的这个内存啊,一直是使用的是1.5并不多,所以我们这个N大多是计算型的,这个大家也很好理解,那就是由于N直接是将所有的东西。
04:17
交给别人,别人才去处理的,他自己也不需要创建对象,也不需要用多大的内存,他把这个结果拿来一返回就行了。他更多需要的就是拥有更多的线程来接收我们更多的请求来进行处理就行了,所以我们CPU呢,要来回在线程之间切换计算,所以我们浪费的CPU比较多,好我们在这持续压测,我们这个压测呢,我们就给它停上一段时间,好我们现在已经压测了57秒了,我们来看它的整个结果报告,这个结果报告里边的有异常,这个异常呢,我们先来看一下,查看结果数,一直往下翻,肯定有哪些异常来点开,我们看这个响应数据,异常呢,它叫socket close,就是我们这个连接关闭了,那这很正常,这是我们手动在这关闭,那有些请求还没完,我们把连接就关闭了,那这个异常呢,我们就不看了,那么整个的这个性能测试,我们大概看这个结果,吞吐量每秒2300,然后它的这个最小值零,那就是请求发过来瞬间返回了,那这也有点太快了,那这个最大值呢是五秒,然后呢,包括它聚合的报告这一块,我们90%的在。
05:26
11毫秒就返回了99%,在900毫秒就返回了那95%,18毫秒,也就是说基本上18毫秒以内所有请求都返回了,这是我们得到的一个NG的性能指标,把这个指标呢,我们来复制,放到我这一块,大家我们一会儿来参考一下,我们的整个吞吐量是2300,我把这个复制过来。好2300,那么吞吐量呢,能有两千三百分之九十的响应时间,大概我们之前看到是十一百分之九十九呢,是944好,我们都放在这90%,十一九四四好,这是我们单压N4。
06:05
我发现N的性能呢也是不错的,而且我们这个服务除了过N,我们还要过一个网关,那么接下来单压一下网关,我们来看一下网关的这个性能指标怎么样,那先把以前的这个结果清空,那压网关怎么样?那这个网关先给得给本机来发送请求local host,我要给本期的八八端口,网关是八八端口,我们直接回车就行了,这个八八端口那默认网关处理返回的是一个404,这个404也算是网关处理得到的一个返回,只是没找到这个请求数据而已。所以我们直接给他发也没问题,好我们就来用这个,我们来复制过来,我们来到我们这个HTP请求这一块,来给本期的这个local house88端口啊,把这块复制过来,来写上local host local host,我们网关呢,主要是我们的八八端口,我们也发送杠这个请求,他找不到呢,就是404,然后呢,我们来看它的整个性能报告,好我们来运行起来。
07:08
好,那我们网关持续期间呢,他在这儿都开始汇总所有的异常都发生了,因为所有的异常我们看结果数里边这块呢,都是404的这个接森数据,那这也没什么影响,那好接下来我们来持续来监控我们整个网关的这个性能指标,Windows r cmt,好,我们使用呢,接微收微的命令,微收V来打开我们的整个监控。后台我们来看一下我们网关到底比较浪费内存还是浪费CPU,还是什么样的好,我们来看一下。好,我们现在呢,启动起来,启动起来呢,我们来直接连接上我们这个网关项目,稍等一下。我们来找到我们这个网关,Gety,我们来连接进来。连续进来呢,我们来监控一下它的整个压测期间的这些指标,来看一下网关的这些汇总报告,那现在还没结束,发现网关的吞吐量还是挺大的,一万多,来看一下这一块监视。
08:06
我们发现网关呢比较浪费CPU,基本上都是百分之五六十,其实我们发现网关的功能,这跟NGS是基本差不多的,所以他们浪费CPU很正常。然后关于内存,这内存还行吧,因为我们给他们分配的内存本来也就不多,连100兆都不够,我们这个顶分75兆,我们发现呢,基本上都没占满,而且我们经常还要进行垃圾回收,我们来看一下这个垃圾回收,我们这个垃圾回收伊甸园区我们的内存只有32兆,超小,所以它的这个垃圾回收次数非常多,花费了八秒多的时间。当然这些时间呢,是包括总运,总运行时间不止我们这段的压测时间,所以大家想如果我们能调整伊甸园区的大小,那我们这个GC的时间是不是就能减少很多呢?那么这个时间一减少了,我们吞吐量呢,又上去了一部分,等等等等,那指标的这一块,我们再来看它的这个线程数。
09:02
鲁网关的线程数也不大,只有五十来个线程。我们放在这好,我们现在来看一下我们整个网关的这个压测指标,我们把它现在停掉,把那一块呢都看完了,好,我们整个吞吐量呢,我们来看一下有一万多一万多。然后呢,90%的响应时间,我们来参照一下90%的响应时间,八毫秒,99%呢,31毫秒,好,我们来记录一下,90%是八毫秒,99%是31毫秒,好,那么发现呢,我们这些中间键的单独来说性能都是挺高的,但如果我们能来对比起来,那为了对比起来我们的效果更加明显,我们可以来写一个简单服务,比如我们发送hello请求,就来返回一个hello数据,我们不来操作实际的数据库等各种页面渲染的复杂逻辑,来看一下简单服务,我们带上网关,带上N这些我们的性能有多少好们呢?先来到我们的product商品服务里边,我们再把这个简单服务,我们之前写了一个,把这个呢,我给大大家打开,我们先来重启我的这个商品服务。
10:10
我现在来看,加上这个简单服务以后,我们这个性能有没有这个损失,那要加这个,我们先来单测一下我们这个简单服务的这个性能。好,我们先来等待它进行来重启,那重启完成以后呢,如果我们来访问我们本地的1万端口local host,好来给他访问1万端口localho的1万端口来访问哈,请求回车,我们现在呢能响应这个数据,但这个我们来看压力测试表现的怎么样,我们在这来,我们来压力测试的是这一块啊,Local host来加上,而且呢,它是1万端口来也放到这,然后呢,我们来访问他的是hello请求好放到这,我们来看一下来压测这个数据,我要把这一块汇总报告,我们一定要先清掉,好,我们来压力测试走。
11:02
好,那这个压力测试呢,开始来看这个汇总报告,吞吐量每秒呢也能达到一万多,说明我们这个只要不处理复杂的业务逻辑,就一个简单返回,我们即使在非常低的内存情况下来看我们的这个商品服务。来看一下我们这个商品服务,我们来连上来。好,我们发现呢,它的这个内存量我们也给的不是很大,也不到100。它的这个线程呢也不多,这个CPU的使用率呢,也还行,百分之五六十,包括我们这一块GC,大家一会儿来监控我们,即使在这种情况下,我们的这种吞吐量都能达到11000,而且我们来看,我们的90%是八毫秒响应,百分之九十九十七毫秒响应,而且也没有什么错误,我们一停肯定会有一点错误,好,我把这一块数据我来统计一下。说明我们在这不加任何中间件的情况下,那每一个东西的这个原生的吞吐量也还是挺不错的,包括它的这个处理响应时间来看一下,90%是八,99%是17,我们来也写到这儿。
12:11
好,18是17。好,但是接下来我们来做上这么一个实验,我先来测试,如果我是网关加上了这个简单服务,好我现在来调整一下网关怎么加简单服务,我希望访问八八端口的hello请求,能访问到我们的这个hello,那相当于那就过我们服务了,那怎么实现这个效果,我就在网关这一块,我来做一个简单的配置,我配置什么呢?我们把这个商品服务除了映射API product这个请求外,他还来映射hello请求,Hello全年直接交给商品服务,由于不是API开始的,也不用截串,好我们现在来把我们这个网关也来重启一下。现在我们来直接访问网关的hello请求,那么就相当于过了网关,过了我们商品服务没过NG好,我们现在来等待一下,那先来访问我们网关的哈请求,先来尝试走。
13:13
好,那么这一块呢,是访问通道,我们来对网关来做这个性能压测,好我们来到解密特里边,这一块呢,我们都停了,我们把它清空掉,好,HTP请求现在还是押网关logo host88,那押网关的hello请求,网关会转交给我们商品服务,商品服务再整回来,那么实际来看,我们网关呢,单个通图量是一万多,我们这个商品服务的hello请求单个也是一万多,那这两个呢,结合起来能有多少,我们就在下边来统计一下网关加上简单服务,好来进行一个压力测试走。好,我们来看我们的整个汇总报告,好,我们来看这个吞吐量,吞吐量呢,我们一直往上涨,能达到3000,嗯,如果测试时间很久的话,它可能峰值能达到三千五六,当然我们现在的这个吞吐量,只要不是大量涨,说明它的这个已经快要到达峰值了,好把这个呢直接停掉,现在三千一是已经基本稳定了,好,我来停掉。
14:14
好,那停掉以后呢,我们把这个吞吐量我们来拿过来,3100,好,我们如果简单服务加上网关吞吐量呢,就变成三千一了,原来两个每人都是一万多,但是这两个一结合变成了3100,再来看。我们的这个响应时间。90%是30毫秒,99%是125,好,90%是30毫秒,99%是125。那我们发现只要过了一个中间价,这个性能损失还是非常大的。那其实大的原因是什么,我们可以来考虑给大家大概计算一下,比如这是我们这个网关,这是我们哈请求。那默认我们hello请求,不过网关的情况下,我们来直接请求,我们有1万的咱们这个吞吐量,每一个请求呢,我们大概我们来给他约定都是十毫秒完成。
15:09
那相当于从发请求到返回给我们用了十毫秒的时间,但是如果我们现在变成加了一个中间件,那中间件呢,大家也当成浏览器,因为微服务也是给他发送HTB请求的。所以呢,我们假设中间件给他发也是需要十毫秒的时间,那我们中间件呢,我们浏览器给中间件发,我们看中间这的这个单独请求。这八三十一,我们平均给他取一个15。相当于么,我们浏览器给中间价这一块呢,我们又多了15毫秒,那么整个请求结束,相当于比原来直接请求多了15毫秒,相当于翻了一倍,那么这个请求耗时翻了一倍了,那么这个吞吐量呢,肯定就能下去一半,那这是由于每一个请求都得有一个线程我们来处理,那么这个线程呢,本来十秒我们处理完结束了,能处理别人的请求。
16:07
但是呢,我们现在慢了一半,那我们这个线程单位时间内接收到的请求就少了一半,我们通吐量呢,那就少了一半,所以我们通过这个简单的衡量,我们也能得到这个大致的结果,所以我们先来看这一块的对比,我们得到第一个结论就是中间件越多,中间价,中间价越多,那我们这个性能的损失越大,性能损失越大。那损失都损失在哪了?大多数都损失在我们这个网络之间中间键进行这些IO交互了。大多都损失在我们这个网络交互了,所以呢,如果我们想要优化,我们可以考虑第一个先来优化我们这个中间价,我们中间价先每秒的吞吐量能上去。
17:00
第二个,他们之间的传输效率要提高,我们买更好的网线,买更好的网网卡,使用更高效率的传输协议等等等等,这都是我们性能提升的这个手段。而且呢,如果我们来全链路测起来,那这个可能就更难了,比如我们再来加上N几,原来我们直接网关加上我们这个简单服务,每秒呢有3000多,现在呢,我们来加上NG来访问古丽me.hello那为什么这样访问就能加上NG了?好,我们来古丽me下的hello来考虑一下,首先我们发送鼓励mail.com请求,只要带上域名,那我们都先会来到NN呢再来转交给我们的网关,网关一看,我们这个hello呢,要交给商品服务,又来了到商品服务。所以呢,我们全链路测下来,它这个性能肯定也会再来掉一大截,好我们现在把这一块呢,我们来都清空掉,那现在来测一个全链路的来测试,鼓励mail。
18:01
我们还是八零端口好,我们来写一个八零来测试这个hello请求,现在呢,三处都过了,既过了我们这个N,也过了网关,还过了我们的服务,来测全链路,好,我们来现在来进行压测,走好压测开始我们来看我们的汇总报告,我们看到吞吐量呢,这有三万多,这三万多那肯定是不对的,我们先来看结果数这一块错误,错误呢都是古力庙这个域名没找到,好们这一块写的有问题,好,古励ma.com,好,我们来重新来进行压测点。COM1定要把这一块写对,好我们来点一个运行。好,我们现在压力测试开始,我们来看我们的汇总报告,那汇总报告现在的吞吐量每秒呢有800多900多,好800,那么就来取一个恒定的值,每秒的800,好,把这个呢,我来复制过来,好,那现在呢,全链路的情况下,我们每秒呢就剩800了,包括呢,我们这个响应时间,我们来看一下90%是88毫秒。
19:03
99%是310毫秒,响应时间呢,也是很稳定,八十八三百一,但是我们通过这个响应时间,我们能完全看到一件事,我们来看先是简单服务,然后过一个网关,再过一个N,每过一个中间件。我们的这个响应时间都会加上一点,虽然50毫秒对于我们人类来说。挺快的,但是对于我们这个大并发计算机来说,它的这个累积效应起来,那我们这个吞吐量就会损失很多,这是我们压测先看到的第一个效果,我们中间件对我们的整个性能的影响还是挺大的,那下一节课我们再来加上我们真正的业务数据,我们再来看我们如果发送真正有功能的服务,而不是发送hello请求,我要菜单渲染,要获取三级分类来看一下整个效果。将会变成什么样子?
我来说两句