苏州优化网站片头制作网站

苏州优化网站,片头制作网站,网站建设和关键词优化技巧,推广营销费背景#xff1a;在进行性能测试之前#xff0c;我们需要了解需要模拟的场景#xff0c;影响性能的因素、软硬件环境。根据最近一次的压力测试#xff0c;把测试过程中遇到的问题以及测试过程进行总结。 测试需求#xff1a;需要模拟用户登录操作进行测试#xff0c;登录…背景在进行性能测试之前我们需要了解需要模拟的场景影响性能的因素、软硬件环境。根据最近一次的压力测试把测试过程中遇到的问题以及测试过程进行总结。测试需求需要模拟用户登录操作进行测试登录成功之后提取浏览器session进行第三方应用跳转动作。整个流程需要3-4个接口才能完成一次完整的动作流程需要共享session。需要达到的效果数据库中存有200万的数据量不同用户并发登录应用跳转TPS5000。01 脚本录制测试之前需要进行脚本录制研究了几种浏览器录制脚本的工具最终选择了chrome插件BlazeMeter进行脚本录制。相比于BalazeMeterBadBoy工具近几年没有更新只支持IE浏览器。而Jmeter自带的代理方式录制脚本需要使用火狐浏览器设置jmeter代理使用也不方便设置代理后录制脚本过程中会影响服务器自身插件、脚本校验等功能在录制过程中往往会遇到一些问题导致服务访问报错而且录制的脚本还需要修改过滤才能提取出真正需要压测的脚本。BalazeMeter可以录制浏览器的操作直接提取jmeter脚本通过域名筛选提取出有效的脚本通过登录之后应用跳转在BalazeMeter中查看保存的脚本dev.*.360.cn域名的三个脚本为登录、初始化、获取应用列表的脚本。其他为跳转到华为应用的脚本。通过BalazeMeter导出Jmx文件可以过滤域名dev.*.360.cn识别成了undefined这个没有关系只要能识别就可以由于压测对第三方应用会造成很大压力因此之后调整了测试方案即只提取自己服务器相关的接口就可以了。选择undefined.undefined域名保存jmx文件至此测试脚本就生成了。Jmeter打开脚本可以看到设置的用户代理02 数据构造导入jmeter脚本在BalazeMeter录制的脚本中直接使用已经配置好cookie管理。Same user on each iteration默认为勾选状态相同用户共用session请求不会返回session信息。要模拟多用户并发需要构造大量的数据jmeter在升级以后可以通过配置关闭Same user on each iteration共享一个用户参数设置多并发就可以模拟多个用户。为了更真实我在数据库中通过脚本调用先添加了2000个用户通过csv文件导入jmeter反复调用线程模拟不同的用户。03 测试优化过程服务器依赖redis和mysql服务器性能配置、数据锁、登录密码验证机制也是影响压力的主要因素需要一个持续的测试、调优过程才能达到最终的效果。刚开始调试脚本使用单机版Jmeter GUI模式进行测试为了方便实时观察持续加压接口请求响应时间、响应结果的变化。漫长的测试优化过程就开始了。第一次脚本调试先设置较小的线程设置1000个线程并发手动循环执行线程执行几次之后发现吞吐量qps400,执行几次之后错误率持续上升这对QPS5000的要求差的太远起初怀疑客户端资源不够导致的QPS上不去找了多台客户端使用GUI以及非GUI方式测试脚本发现运行一段时间后出现大量的502等错误。因此排除了客户端的问题。通过服务端查看CPU发现8核16G服务器15个pod cpu、数据库CPU在压力请求时瞬间打满。从服务器CPU、内存参数来看理论上不应该这么小的压力瞬间就出问题。后来经过研发分析代码发现代码中的数据库、redis锁以及密码验证机制会影响性能为了进一步确定问题搭建了同样的环境重新编写了单纯的访问接口进行压力测试发现单纯的接口访问在单pod环境下进行压力测试qps能达到1.5万以上经过分析还是代码逻辑影响性能很大。又经过代码调整对登录接口进行优化分别对优化前的login接口和优化后的loginR接口进行单pod压力测试做性能对比发现loginR QPS单pod1000,而login接口QPS200。性能还是有很大差别。之后优化接口后同时扩大副本数量进行压力测试单客户端的jmeter也不能满足QPS5000的性能压测之后采用metersphere进行压测,线程并发最大设置为10000用四个压力节点进行测试。发现qps不是按照指定目标成倍提升的持续一段时间后错误率明显提升。观察redis发现redis分布中有很多响应超时的现象,redis内存占用率很高之后调整redis扩大集群方式调整redis读取锁时间、内存释放配置等重新进行测试。经过不断的调整最终qps达到6000的效果。04 后续数据库数据增至200万发现登录接口qps9000qps与之前的测试结果不符经服务端分析没有读取到数据库修改后发现数据量为200万时qps与小数据量差别不大仍为6000qps。之后又做了读写并发压力测试写入测试的时候为了避免数据冲突通过beanshell前置脚本生成不同的用户保证每次执行都是插入新的用户修改后压力测试读写并发6000qps。总结压力测试过程中影响性能的因素很多并发线程的数量数据量大小redis、mysql数据库配置、程序处理逻辑、内存、CPU配置等都会对压力有影响需要针对不同场景进行测试、对比发现影响性能的因素通过不同的并发场景观察CPU、数据库、redis压力响应时间的变化找到程序执行的痛点达到提升性能的效果。测试过程中也要观察服务端线程是否按照预期正常执行防止遗漏处理逻辑导致测试数据不准确。最后作为一位过来人也是希望大家少走一些弯路在这里我给大家分享一些软件测试的学习资料和我花了3个月整理的软件测试自学站这些资料希望能给你前进的路上带来帮助。​视频文档获取方式这份文档和视频资料对于想从事【软件测试】的朋友来说应该是最全面最完整的备战仓库这个仓库也陪伴我走过了最艰难的路程希望也能帮助到你以上均可以分享点下方小卡片即可自行领取。