网上看一些性能测试的视频, 基本入门就是教我们使用jemter , 或者loadrunner 这种工具对接口的性能进行基本的测试, 但是在实际工作中, 性能测试的指标就只有这些了吗?
性能测试的工具入门
具体的就不讲了,网上免费的课程一大堆, 只是对脚本工具的使用, 不需要太深入, 会看性能指标, 会传参, 会提取即可.
但是在实际工作中, 想要拿到性能测试时期的性能真实指标, 就需要在服务器上有一个探针, jmeter 工具里有一个探针插件可以获取被监控的服务器的CPU, IO, 读写速度等． 但多数情况下, 运维是不会给你安装ｊｍｅｔｅｒ这个工具的探针的， 因为他们也不知道你用的是ｊｅｍｔｅｒ哪个版本，不同版本的插件还不一定好找，并且服务器上一般能不安装多余的插件都不会安装． 在ｓｑｌ ｓｅｒｖｅｒ 里有性能监控器， 可以建立一个监控任务，然后在脚本跑之前进行开启； 在 ｃｅｎｔｏｓ 上， 也有一个这样的工具， 用命令行进行开启监控， 使用 mpstat 即可, mpstat -P ALL 1 > status.log
其实前端也是有性能的
以前就听说过, 前端也是有性能的, 但是由于我上家公司的业务体量不是很大, 所以没有感觉到很明显. 现在在职这个公司的业务数据量比以前的大, 加之最近公司就是准备对项目的性能进行优化, 参与了优化的讨论和技术点的改进, 这才深入了解了一些前端的性能.
前端的性能差, 主要有以下的几个方面:
1.没有增加用户界面的交互逻辑, 比如现在有一个批量且数据量大的插入动作, 用户在前端界面进行了这个操作, 然后页面就一直在转动,也没法进行其他的操作, 就会让人明显感觉到系统卡顿.
解决的方法: 增加用户界面的交互, 当大量数据插入的时候, 出现一个loadind的界面,用户关掉它就可以回到界面上继续再做其他的事情
2.前端对业务逻辑的二次处理太多
前端慢, 有时候和业务逻辑有关, 后台的接口并不能一次拿到就处理当前的业务, 有时候需要前端对后台返回的数据进行取值再叠加等操作 , 有的时候需要前端拿到上一个接口的数据和当前的接口数据进行再次处理, 更有的时候前端还要执行轮询拿到某个关键接口的数据. 因此这些组合在一起, 就会导致前端的性能变慢.
解决的办法: 优化流程中的前后端交互, 尽可能减少前端对业务逻辑的二次处理, 改成尽量由于后台来分发数据
3.对产品的设计和前端优化同步
在前端某个模块,产品开始对这个模块有差异化的需求时候, 前端就可以要求产品给出具体的业务差异化, 将公共部分抽离出来, 最后再根据业务逻辑将差异化的部分加载出来, 这样前端的渲染就会快很多.