快乐学习
前程无忧、中华英才非你莫属!

读性能测试书籍之读后感1

前言

好久没有一天一本书的习惯了,之前因为搬家,书比多的原因,一直遏制买纸质的冲动,看到新出的书,在没有电子

书的情况下,没控制了,又买了。看了下标题,业内专家联合推荐软件性能调优之路,看到专家之后,我认为对俺们的技术应该是有些帮助的,有些可能遗漏的点,在补足一下。
书名:软件性能测试,分析与调优实践之路
再看完目录之后,卧槽,对我的技术增长几乎没哟,对大部分的萌新还是很有帮助的,通过多年买书经验,专家推荐、书很薄
就是理论和一帮原理的介绍。这里也不是对作者的冒犯,我只是对本次读书,做一个读后感。

此次不会贴书的截图,只是用小编的大白话,来通篇讲解本书的内容。

书籍目录的介绍


1、性能测试基础理论的介绍,

无非就是性能分类,测试场景,

性能测试指标(tps,qps,响应时间,用户并发数,pv,uv, 点击率,吞吐量、资源开销)

还有什么性能需求分析,性能测试流程,性能测试方案,这些基本没啥用,毕竟每家互联网公司,应用架构不一样,人员配比不一样。

那些百度百科的理论,基本用处不大。 你说一个简单的BS架构的软件,一个开发用工具压一下,设置下场景,看下性能指标就ok 了~


2、性能调优技术
这块是比较重点,因为模拟并发,工具使用、其实都很简单,最主要是如何调优,如果你知道如何调优,其实就已经知道
软件的性能瓶颈一般都会出现在什么地方。


2.1  缓存调优

现在的应用都会上缓存Redis,CDN, 数据库缓存,静态资源缓存等等。

分的精细一点 浏览器缓存,app本地缓存,web服务器缓存,应用数据缓存,数据库缓存。
书中说了缓存调优的关键点:  我觉得书中比较啰嗦,帮他总结了一下

1、提高缓存命中率。

2、防止缓存穿透。
3、控制好缓存失效时间。
4、做好缓存的监控分析
5、防止缓存雪崩。

我看了下作者之前是做开发的,因为这些问题,都是开发需要考虑的问题,说不好听点的,现在开发出去找工作,

这5点是必问题目.  关键书中最关键的5个点,用5个问号说明的,测试工具没有说,测试方法没有说,你既然抛出了问题。
起码给个答案吧?
关键可笑的是问题是:防止缓存穿透,控制缓存失效时间,做好缓存监控分析,防止缓存雪崩,后4个点,都是为了要提高缓存命中率丫
哥们!你这是用开发的专业术语,来凑字啊!
书中没有答案,小编给出答案:
互联网应用,最实用的缓存代表作:Redis.数据库
首先说下缓存命中率的概念:
命中:可以直接通过缓存获取到需要的数据。
不命中:无法直接通过缓存获取到想要的数据,需要再次查询数据库或者执行其它的操作。原因可能是由于缓存中根本不存在,或者缓存已经过期。
通常来讲,缓存的命中率越高则表示使用缓存的收益越高,应用的性能越好(响应时间越短、吞吐量越高),抗并发的能力越强。
由此可见,在高并发的互联网系统中,缓存的命中率是至关重要的指标。

1、检查命中率

首先是查看它的命中率,通过info 命令可以获取当前服务器的缓存数据的指标:
缓存命中率计算公式: keyspace_hits / (keyspace_hits + keyspace_misses)
通过工具 https://github.com/junegunn/redis-stat

得出Redis缓存中间件的性能数据,如果看不懂,恶补一下Redis的基础。

redis命中率不高问题排查
下边是今日性能测试中遇到的问题,总结如下。
1、 问题
测试某接口时发现redis中的keyspace_misses一直在增加,即未命中数一直增加。
2、解决分析过程
1) 使用dbsize命令查出来的keys数大于keys *|wc –l统计出来的数,说明有过期的key存在。
2) 执行flashall清除全部数据。
3) 重新生成一批新数据。
4) 使用dbsize命令查出来的keys数等于keys *|wc –l统计出来的数。
5) 测试时监控未命中数,此值未再有所改变,命中率为100%。
3、总结
当有过期的key存在时,会导致命中率不是100%,首先可以使用dbsize命令查一下keys数,再用keys *|wc –l统计一下keys数,若不相等就说明有过期的keys存在。


2、提高命中率

如何提高命中率,不是我们测试人员思考的,我们只要检测出来,然后给架构师或者缓存设计者几个建议,
通过缓存预加载(预热)增加存储容量调整缓存粒度更新缓存等手段来提高命中率。


3、防止缓存穿透

首先解释一下缓存穿透的概念,查询一个根本不存在的数据,缓存层和存储层都不会命中。
如何检查,很简单,对某个接口测试、构造好模拟数据之后,实施并发测试,查看一下后端MySQL类的持久化数据库的访问记录。
检查MySQL后面的查询记录。如果MySQL;查询记录有大量重复,那肯定个就是穿透无疑了。
产生的根本原因就是业务代码本身逻辑和并发逻辑代码控制的问题。
优化呢就是在Redis里面缓存空对象,以及增加布隆过滤拦截。


4、检查和控制缓存失效时间

相对检查还是很简单,先把redis  里的key  ,flush 清空一下。
咱们做接口压测的时候,会对应的在Redis 生成key.
然后通过控制端 命令 > ttl key 来查询缓存失效时间。对比一下需求,看看。


5、防止缓存雪崩。

其实就是对Redis 集群的检测,就是把一个正在受业务访问的Redis的进程杀掉,看看其他Redis 服务是否可以正常提供服务。
用户体验和返回数据,和正常一样,让用户感受不到后端 某个redis 服务器挂掉了而带来的卡顿和响应缓慢。并且访问的数据是一致的。


2.2  同步转异步调优

同步:请求在后端没有处理完成,就一直不返回结果,那显然有大量图片的时候,阻塞很严重。
异步:后端收到请求,立即把请求接收成功返回给调用者,在请求处理完成后,在异步推送处理结果给调用方。
或者请求调用方间隔一定时间之后在重新来获取请求结果。
现在的京东淘宝,都是异步的,假如在下拉右侧滚动条的时候,才会触发下面商品图片和信息的加载。

2.3  应用的拆分

看书中的解释很懵,她说的意思应该就是,微服务架构。把复杂项目进行模块拆分。每个模块当一个独立项目安装部署,
他们靠RPC进行通讯, Java 电商领域用的比较多的是Dubbo  和Spring cloud。
系统拆分的好处就是在高并发的业务不会对低并发的业务的性能造成影响,而且系统在硬件扩展时候,也可以有针对性的进行扩展。


2.4  任务分解与并行计算

作者直接给了个,类似于Hadoop 分布式系统处理的图片,告诉分布式的好处。把一个请求任务,拆分成多个
然后用多线程程序进行处理,然后返回最终结果。它这是在分布式的好处还是啥,太恶心了~~~。

2.5  索引与分库分表

作者简单来说,告诉数据库加索引,以及分库,分表的好处。
小编插一句嘴,在我们做性能测试的时候,只要把模拟的数据对数据库的字段,覆盖全一点。就行了~
然后在检查一下数据库的慢查询语句,看看哪些字段没有加上索引。 分库,分表,以及数据库主从集群的策略,
一般是DBA,或者开发的事情。
我们只是瞅一眼,分库,分表,起没起作用。策略有没有生效。

3、Linux 系统监控与分析
书中提到的估计也是作者常用的检测命令了
有vmstat、mpstat、pidstat、lsof、free、top、iftop、nmon
这些命令没什么大同小异,只是侧重点不一样,唯有手熟和注意一些参数技巧的组合,然后弄懂每个命令打印出的指标即可。

4,5,6
其他的就是Web 中间价Nginx 一个 介绍,配置调优、而不是测试调优。乱乱的,不明白作者这本书,是给测试开的,还是给开发看的。还有就是tomcat 的原理介绍,配置调优,Jvm 介绍,和监控,最后是MySQL的基本的连接数配置,和监控,
以及如何查看慢查询。

最后小编总结一下性能测试到底有多简单:
1、模拟比较全面的用户数据,构造多并发请求。
2、监控(各个组件的日志、状态)
3、根据自己对某个组件了解检查出原因。给出建议。
4、最后开发、架构、优化、
5、我们再次构造并发请求,再次监控,从监控可以看到,系统资源消耗稳定无异常,各个组件监控也比较稳定、并发请求数量对应增加,符合需求。
6、性能测试完毕,进入下一环节~。

打赏

未经允许不得转载:同乐学堂 » 读性能测试书籍之读后感1

分享到:更多 ()

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

特别的技术,给特别的你!

联系QQ:1071235258QQ群:226134712
error: Sorry,暂时内容不可复制!