自己电脑做网站用备案毕业设计代做网站jsp

当前位置： 首页 > news >正文

自己电脑做网站用备案,毕业设计代做网站jsp,影视软件开发定制,用电脑做网站六、性能测试流程#xff08;如何做性能测试#xff1f;) 根据学习全栈测试博主的课程做的笔记 1、前期准备– 项目初期就开始#xff0c;业务需求评审时尽量参与,对业务更深刻的认识#xff08;确定哪些是核心业务、哪些可能存在并发请求、确定什么地方会出现瓶颈,方便后…六、性能测试流程如何做性能测试) 根据学习全栈测试博主的课程做的笔记 1、前期准备– 项目初期就开始业务需求评审时尽量参与,对业务更深刻的认识确定哪些是核心业务、哪些可能存在并发请求、确定什么地方会出现瓶颈,方便后续性能需求评审时给出建设性建议 2、性能需求分析、评审确定性能测试的范围、性能测试的目标是多少 2.1、确定范围哪些业务接口 使用多的、核心业务功能 2.2、目标tps、rt、成功率、资源利用率等 2.3、补充 2.3.1关于需求来源项目组一起定性能目标 2.3.1.1迭代项目 1范围 新增、修改、受影响的功能也是需要放在压测范围内 2目标 不能低于之前版本的性能 还需要进行容量评估根据历史数据的请求数据进行统计月增长率是多少 比如现在要做一个容量预估可以根据增长率业务、用户增长的情况预估tps达到多少未来才能满足业务需求就可以做容量预估 3业务比例类似ELK的日志平台来统计 从生产上统计接口的业务比例(其实就是单接口的比例 这只是统计出接口的比例但是需要转换成业务比例评审时就需要将业务比例获取到最后在jmeter设计场景时要用到。 2.3.2新项目 1范围核心业务功能 2目标值参考竞品、经验值产品经理 若是迭代项目可以和之前的版本性能做对比也可以通过生产环境的统计日志获得容量tps新项目就是参考竞品和产品经理的经验。 3补充①业务比例项目组谈论、项目运行后统计②要测出最大容量Tps为上线后限流提供参考 迭代项目的业务比例是可以通过类似ELK日志平台拉取数据看一下压测时间范围内各个接口请求的压测业务比例历史数据统计新项目没有历史数据怎么解决 这种新项目的业务比例只能是项目组进行讨论不好定的情况最简单的就是11或者就是项目试运行后数据统计比例,少量用户和大量用户使用的tps有差异业务比例的1偏差不是太大。 对于新项目一定需要测出最大容量tps为上线后限流进行提供参考。 3、制定性能测试方案为后续工作进行指导 方案很重要(设计相关的、数据的设计、场景的设计、监控的设计等 3.1、项目背景 描述项目做什么、核心业务什么、出现什么问题系统架构用到什么技术栈 1背景描述 2系统架构 了解系统架构、用到什么技术栈、接口的的数据流向、经过了哪些技术栈才能为后续设计监控提供参考才知道去监控哪些服务 3压测目的 解决当前什么性能问题、还需要测试出系统的最大容量tps(为上线后续的保证服务不挂、限流等 3.2、术语说明主要为了避免理解偏差 1tps 2rt 3并发 4业务比例 5单场景 6容量场景混合场景 7稳定性场景 3.3、测试范围、目标 1要压测的接口清单以及业务比例 2各个场景的目标tps、rt、成功率等 3.4、测试资源 1人力资源组织架构 项目经理(协调压测需要的资源 性能测试工程师编写性能测试方案、性能测试脚本、设计压测场景、执行压测、收集监控数据、编写测试报告等) 开发工程师开发需要配合性能测试进行打对应的压测分支、做性能分析、做性能优化 运维工程师配合性能测试部署压测测试环境、协助性能部署测试监控 2压测工具主要是压力端的工具 jmeter还是loadrunner 压力机window、linux 如果对性能要求不高用window压力机即可一般用的是linux 3压测环境 硬件、软件、部署描述清楚 3.5、压测设计最重要 1数据设计 ①参数化数据—数据量–根据业务来 唯一性tps500压测时间600s至少需要30000数据量乘以20% 非唯一性tps500也是时间600s至少覆盖线上时间被使用到的 如注册要用不同的用户名系统要求用户名是唯一就需要准备不同用户名。 模拟不同的真实用户发送请求。 参数化数据设计多少得根据业务来对数据有唯一性。 若要求tps500压测时间10分钟600s,至少需要30000数据量但是压力端在发送请求时不是轮流发请求假设起了200个线程jmeter线程关系之间也是有竞争关系也是要去争夺cpu的执行权限。如果获得cpu的执行权限就将请求发送出去可能有的线程获得cpu执行权限多一点发的请求数也会多jmeter数据量把,一部分数据分成线程1线程2线程3获得cpu的执行权限不一样为了避免发的请求更多数据量不够再算出的数据量再乘以20%或者更多 对数据若没有唯一性。如查询商品a\bc都可以查询到电脑商品表有10万个商品数据量应该设置多少假设tps500压测时间10分钟600s至少需要30000数据量商品表里有10万数据可以直接用也可以直接统计线上某一段时间内哪些商品被搜索再进行参数化需要与线上覆盖到实际被使用到的数据 参数化唯一性数据需要自己造 非唯一性数据在库里存在若想所有数据都需要参数化数据导出若想拿某一些热点数据进行参数化就需要统计线上日志。 ②数据库存量 数据库里各个表都存有数据测时的数据库量级与生产一致方便复现线上回归压测复现问题变量太多尽量保持与生产一致数据量级、环境差异、软硬配置 数据库的表和生产量的数据库表的尽量保持一致 2场景设计单场景、容量场景、稳定性场景等 ①单场景 单个业务接口进行压测 生产环境有很多的业务功能,一般说系统的tps都是混合容量的tps为什么还需要对单场景进行压测?单个接口链路简单可以发现明显的性能Bug可以为后续混合场景tps参考代码逻辑性能Bug、软件配置bug如数据库连接配置应用代码线程池里的配置 ②容量场景混合场景 容量场景一定需要集合业务比例模拟线上真实业务场景在性能需求评审时不仅要给到目标tps还需要给到业务比例因为线上环境每个接口调用次数不一样。 涉及到有用户登录、查询商品、添加购物差、创建订单接口若对这些业务做单场景测试这四个接口就属于压测范围。 单场景就是针对每一个业务(单独的接口去进行单独指定目标、设计到加压方式、表的数据量脚本涉及到关键点以及重点关注相关指标 根据图中的单场景的目标tps是300、500、500、200一般性能测试中给出的tps都是混合容量的tps。 混合容量tps800接口业务占比可以根据业务比例算出在混合容量场景各个接口的tps。创建订单 业务比例10%总的tps是800则创建订单接口的tps为800*10%80 其他接口也是同样算法根据混合容量总的tps算出各接口在混合容量场景下的tps 单场景若没有指定目标tps接口的目标tps至少是需要比混合容量场景中各接口的tps高有的项目组会告诉单场景的tps有的项目组则不会告诉单场景的tps不指定的话根据总混合容量场景tps和业务比例是可以进行算出每个单接口的tps需要达到多少 图中的业务比例是日志平台统计业务峰值容量tps分解出来各个接口的比例在jmeter中设置的时候还需要进行转换(吞吐量控制器 业务占比用户登录15%查询商品40%添加购物车35%创建订单10%根据日志平台线上系统进行统计有并发请求的业务的一个量后面再根据jmeter的吞吐量控制器进行业务比例转换 ③稳定性场景防止系统在高峰值时挂 压测时需要设置一个持续时间,jmter中循环次数勾选永远会设置一个持续时间 稳定性压测时间设置多少合理jmeter中tps总请求数/并发时间 并发时间总请求数/tps 5000万/80062500s–建议,时间乘以120% 50000万/100050000s,建议时间乘以120%防止跑到后面后性能下降后没有达到5000万的业务量 稳定性场景的tps用的是混合容量场景测试出来的最大tps1000用更大的tps跑出更少的时间。 ④加压方式 秒杀、抢购—-瞬间产生压力 非秒杀、抢购—–逐步阶梯加压 3监控设计 根据压测接口的链路涉及的技术栈、选择合适的监控工具 比如链路监控工具是微服务的标配服务很多排查问题难 java项目:通过链路监控工具进行时间拆分发现是应用耗时多对应用接口的调用的方法通过arthas之类工具看哪个是方法耗时多或者可能是jg在耗时通过jdk自带的相关命令进行查看jstack 系统架构、数据流向、技术栈需要清楚 3.6、测试计划 流程的一个里程碑计划、产出物什么、时间节点、负责人是谁 3.7、风险评估 根据当前情况罗列出可能的风险如涉及到外围系统外围系统也属于外围风险、人力资源缺少、环境差异 3.8、参考资料 4 、性能测试方案评审 写好后项目组进行评审、性能测试计划、性能测试场景怎么设计的. 根据评审会议的建议进行修改 评审会议通过后需要发送给各项目组的成员 5、申请性能测试环境 简单架构nginx2 tomcat mysqlnginx做反向代理tomcat容器有两个mysql看哪一个服务是影响大的资源不足的话对对应的服务等比例缩放进行两次压测看损耗率。 初步判断瓶颈在应用层第一次是一个tomcattps是100两个tomcat的tps是180此处有20的tps的损耗。换算成损耗率生产是3个tomcat预估可以达到多少tps现在简单架构较少一般都是复杂架构复杂架构链路长涉及的服务多每一个服务的影响因子性能大小不一样很难换算。建议项目组进行评估做好线上的保护如限流。 大公司一般压测环境不足一般是直接线上全链路充分利用线上的资源。 补充新项目可以直接在线上环境压测 6、性能测试用例编写及评审 性能测试用例设计一般是对性能测试场景进行设计 对单场景、混合容量场景、长时间稳定性的设计重点就是各场景里的数值 单场景(目标tps、加压方式、数据量、脚本设计等 混合容量场景业务比例、目标tps等 长时间稳定性总的压测时间、总的目标业务量等 7、搭建测试环境 参考测试资源压测环境的部署 除了部署应用还需要部署监控 8 、准备测试脚本、测试数据 8.1、脚本 推荐开发提供压测环境调通的postman或者jmeter脚本 或者根据接口文档写swagger 8.2、场景设计 8.3、准备数据 1参数化数据 方式代码生成从数据库导出 2数据库存量数据 方式 复杂表jmeter跑业务接口 单表代码存储过程 9、环境确认测试 9.1、静态测试 确认环境配置软件、硬件尽量和生产保持一致 软件jdbc的配置、线程池的配置等是否和生产保持一致 9.2、非静态测试 确认环境是否可用压测的接口是否通、发送请求是否有响应响应结果是否正确等 10、执行压测并监控 先单场景测试发现明显的性能bug,为容量场景做准备 混合容量场景模拟真实线上的真实场景 再执行稳定性场景 执行压测监控时不要一次性打开所有监控监控也是需要耗费监控资源。先通过jmeter非gui模式下持续阶梯加压跑一下看一下结果如不达标后若是微服务用skywalking是哪一个节点耗时多就着重监控不达标的节点如果是mysql服务则将mysql的服务打开通过mysql监控看是什么问题若有慢sql后续就需要出现问题的接口执行的sql拿出来用explain单独分析sql执行情况 每一步需要哪个监控就开哪个监控 11、分析定位 11.1方法 1简单架构 查看资源消耗,通过监控发现应用服务器的CPU高java项目可以进行打栈看一下线程在做什么下一步就是代码逻辑。 2复杂架构 通过分解时间方式微服务skywalking 举例 场景比对加节点 怀疑是服务资源不足可以进行加节点 性能提升后就是服务资源不足导致的服务为什么消耗资源代码逻辑是否合理。 隔离:这个功能会调另一个功能先将一个功能去掉后再进行压测。 12、性能优化 13、性能回归 14、编写性能测试报告 14.1、测试过程详情以及对应的分析 14.2、测试问题总结及建议 14.3、问题汇总 14.4、风险评估 14.5、优化清单