企业官网建设流程全解析

网站制作公司 知乎,中国建设工程机械网站,wordpress二次元主体,石家庄建工科技学院石家庄做网站前言 性能测试大致分以下几个步骤#xff1a; 需求分析 脚本准备 测试执行 结果整理 问题分析 今天要说的是最后一个步骤——“问题分析”#xff1b; 需求描述 有一个服务#xff0c;启动时会加载一个1G的词表文件到内存#xff0c;请求来了之后#xff0c;会把…前言性能测试大致分以下几个步骤需求分析脚本准备测试执行结果整理问题分析今天要说的是最后一个步骤——“问题分析”需求描述有一个服务启动时会加载一个1G的词表文件到内存请求来了之后会把请求词去词表里做模糊匹配如果匹配到了就向一个后端服务发送一条http请求拿回数据之后返回给客户端的同时向mysql记录请求的唯一标识和一个请求次数的标记其中有几个关键函数模糊匹配fuzzyMatching后端请求函数sendingRequest拼装请求函数buildResponse记录mysql请求次数标记signNum问题及分析第一组完全随机请求词qps达到1k时服务器未见异常cpu、内存、带宽均未满qps无法继续提升分析由于此服务后端连接了其它服务所以在压测之前要确认后端服务不会成为瓶颈点目前的状态很可能是后端服务限制了被测服务的性能此时可以检查后端服务所在机器的各项指标或者查看本机的连接状况一般后端服务无法处理而被测服务又会一直向后面请求的话timewait状态的连接会变得比较多第二组解决后端服务的问题后第二组使用平均30个字的请求词来打压qps到400时cpu load已满分析这种情况明显是由于fuzzyMatching函数计算效率的问题导致cpu满载从而无法提升qps使响应时间不断增大此时可以通过perf火焰图来确定整个处理请求过程中响应时间长的函数此时需要评估压测数据是否合理如果线上平均请求词只有2个的时候此组测试明显不合理此时要开发进行性能优化就是浪费时间的如果评估测试数据合理可以再次更换短词数据进行压测验证猜测第三组解决了上述两个问题之后使用完全随机请求词qps到达3k后降低至1k然后再次提升到3k如此反复分析此时关注一下各项指标排除了以上的问题的话操作mysql慢的问题可能性大一些对这种需要高并发的系统来说直接读写mysql不是个聪明的解决方案一般会用redis做一层缓存这里说道的另一个问题就是开发设计不合理导致的性能问题第四组将后端换做真实的服务来做整体压测发现qps最高只能到300此时检查各项指标发现入口带宽占满了分析这次问题比较明显后端服务返回内容过大导致带宽被占满此时依然需要评估需求1、是否需要后端返回的所有数据内容2、评估更换万兆网卡的性价比3、是否可以通过技术手段优化带宽占用比如把一次请求分散到多组服务的多个请求perf火焰图定位函数问题这里简单说一下如何使用perf火焰图来直观的定位性能问题perfPerf 拥有了众多的性能分析能力举例来说使用 Perf 可以计算每个时钟周期内的指令数称为 IPCIPC 偏低表明代码没有很好地利用 CPU。Perf 还可以对程序进行函数级别的采样从而了解程序的性能瓶颈究竟在哪里等等。Perf 还可以替代 strace可以添加动态内核 probe 点还可以做 benchmark 衡量调度器的好坏。使用举例perf record -e cpu-clock -g -p 11110 -o data/perf.data sleep 30-g 选项是告诉perf record额外记录函数的调用关系-e cpu-clock 指perf record监控的指标为cpu周期-p 指定需要record的进程pid生成火焰图1、第一步使用压力测试工具对程序进行打压压到程序拐点$sudo perf record -e cpu-clock -g -p 11110Ctrlc结束执行后在当前目录下会生成采样数据perf.data.2、第二步用perf script工具对perf.data进行解析perf script -i perf.data perf.unfold3、第三步将perf.unfold中的符号进行折叠./stackcollapse-perf.pl perf.unfold perf.folded4、最后生成svg图./flamegraph.pl perf.folded perf.svg到这儿可以生成函数调用火焰图如下图原生的perf可以直接定位C/C的程序通常编译debug版本的程序能看到更多的信息java、go等语言可以通过各自定制的工具来生成原理类似通过火焰图可以轻松定位到哪个函数的处理时间最长从而找到问题所在结尾本文YY了一个项目YY了一些场景来分析一些真实的性能问题平时的性能测试中遇到的问题远比文中列举的多有代码逻辑问题、服务器配置问题、服务部署问题、甚至需求合理性的问题每个问题都有自己分析定位的套路掌握了这个套路就可以解决各种问题大家可以留言分享自己遇到过的性能问题及分析过程和最终的解决方案丰富这个套路~感谢每一个认真阅读我文章的人礼尚往来总是要有的虽然不是什么很值钱的东西如果你用得到的话可以直接拿走这些资料对于【软件测试】的朋友来说应该是最全面最完整的备战仓库这个仓库也陪伴上万个测试工程师们走过最艰难的路程希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取