1.首先我们测试Nginx,Nginx进程在运行在192.168.56.10(虚拟机ip)的80端口
聚合
可以看到,90%请求在4ms内返回了,99%请求在726ms内返回了,吞吐量是5,668
2.在测试Gateway,Gateway进程运行在本机的88端口
聚合
可以看到最快0ms完成,最慢117ms完成,吞吐量15211,90%请求在10ms内返回,99%请求在22ms内完成,可以看出,可以看出网关的性能还是很不错的。
3.测试简单服务,映射一个hello,请求
聚合
可以看到,最快0ms完成,最慢394ms完成,吞吐量20027, 90%请求在8ms内完成了,99%请求在12ms内完成了,简单服务的性能也很不错。
4.下面我们测试网关+请求服务,发送请求到网关,在由网关转发给我们的服务,相当于在用户和简单服务之间加了一个中间件
聚合
可以看到,最快在1ms完成,最慢211ms完成,吞吐量为6252,90%请求在34ms内完成,99%请求在73ms内完成
5.测试全链路,请求->nginx->Gateway->简单服务,在原路返回。
聚合
可以看到,最快在5ms内完成,最慢在484ms内完成,吞吐量677,90%在200ms内完成,99%请求在290ms内完成,吞吐量一下子姜了好多。
汇总一下所有
对比一下,简单服务和网关+简单服务,看一看出来,吞吐量从20000-6000,大约变为了原来的三分之一。
我们简单分析一下,简单服务响应时间取(8+12)/2 =10ms,网关取(10+22)/2 = 16ms
通过粗略的计算,我们大概也能算出来,可以看出,中间件越多吞吐量就越低,中间件对性能影响很大,
如果在在上边的基础上在加上nginx的话,总响应时间=请求到nginx+nginx到网关+网关到简单服务的时间,得出的吞吐量与上边测试出来的吞吐量差不多。
6.压测首页一级菜单渲染
聚合
可以看到最快在3ms内完成,最慢1949ms完成,吞吐量为420. 90%请求338ms完成,99%请求604ms完成。
简单分析一下
首页一级菜单渲染比简单服务多了两步,一部是db,一步是themleaf的渲染,所以他的性能消耗主要是在db和themleaf.
7.压测三级分类数据获取
聚合
可以看到最快在16392ms内返回了,最慢在17373ms内返回,吞吐量为5.7,90%在17285ms内成功返回,99%在17372ms内返回。
简单分析一下
三级分类数据获取相比于简单服务主要多了db,吞吐量从20027->12.8 主要性能消耗在db。
也可以观察到,在此期间进行了好多次的小gc和几十次的大gc,如果能增大伊甸园区的话,小gc次数就会减少,性能也会有所提高
,
8.测试首页全量数据获取
聚合
可以看到最快2649ms完成,最慢5412ms完成,吞吐量为19.8,90%请求4589ms内返回了,99%请求4933ms返回了。
首页全量数据获取相比于首页一级菜单渲染多了静态资源这一步,吞吐量从819->19.8,主要是由于获取静态资源。
最后的压测表单