一，后端性能测试
1，接口性能测试
1.1，接口的处理逻辑
梳理接口具体的处理逻辑，是直接调下游接口，获得数据后透传，还是做了逻辑处理再入表，还是插到redis中
1.2，接口整个调用链路
了解压测的这个接口，调用下游具体哪个服务中的哪个接口，这个下游再调用下游。是从表查还是从redis中查
1.3，根据业务量构造压测数据
根据实际业务峰值，构造压测数据量。避免因压测数据量或目标QPS未达标而导致因性能问题出现业务问题。按照80%打到20%时间的比例，先按80%计算业务量，再按20%时间，计算到秒时，有多少QPS。
特别注意点有些业务量需要考虑时间长短，时间长业务数据量到后面越来越多，当数据量大时，再从这个数据量大的表中查数据时，返回的时间可能越久。
1.4，观察性能指定
这个包括产生的QPS，CPU利用率，内存使用率，错误率，以及压测过程中的下游资源情况
2，混合场景压测
单接口压测是针对某个功能出现峰值的压测，但实际上，各个业务场景都是同时进行的，比如同一时间段内，有的用户的登录 ，有的用户在下单，有的用户在付款。为了模拟更加真实的业务场景，就需要混压。
2.1，混压场景设计思路
先梳理混压场景下包括具体哪些功能接口，以及业务数据流向。因为有些可能还包括消息的消费，数据入表，数据查询，功能逻辑处理。
2.2，设置混压比例
比如，一个混压场景下有5个接口，之前己经完成了5个单接口的压测，现在把这5个接口在jmeter中分别按100%的比例设置：A接口目标是200QPS，B接口是400QPS，C接口是500QPS.把这3个接口的QPS汇总，再按对应的目标QPS计算出每个接口的占用比例
2.3，目标QPS
混压场景下每个接口的目标QPS比单接口压测时低50%左右都算正常，比例单接口压测是1000QPS，混压时只要不低500QPS即可
3，常见压测原因分析
3.1，QPS上不来
这个有多种原因导致，如：本身的代码处理，受下游影响，资源不足，缓存等
3.2，资源利用率高
有些高频接口，消耗CPU资源大，当大量请求过来时，CPU资源就跟不上，此时就得加资源解决
3.3，下游响应时间慢
下游接口响应时间慢，导致拿到数据的这个过程慢，影响QPS
3.4，没有利用redis
没有充分利用redis，需要实时请求下游或从表中查数据。这个需根据实际业务场景，比如有些数据是查上周的数据，或者有些数据不需要实时的，可以用redis存起来，再请求时从redis查，就快很多。
3.5，redis的KEY过长
有些大KEY的redis也会导致QPS慢
3.6，下游接口调用方式
有些接口在调下游时采用串行的方式，要更改为并行的方式调用。还有些一个接口要调多次，需下游优化改为一次把多次调用的入参传过来，不需要多次入参多次来调用，比如查3个日期的数据，兼容下，一次传3个日期，在接口中用LIST区分，然后一次返回
3.7，慢SQL
有些请求涉及SQL查询，需结合日志分析查询得到结果的时间长短，如果大于1200豪秒，基本算是慢SQL需要优化
3.8，分页查询或一次性查询
有些数据量大的，后端接口要加页码查询数据，不需要一次性把所有数据查出来，否则也很慢
3.9，SQL相关
有些SQL没有建索引，有些是SQL的写法不对，比如，避免用like查询
4，kafka消息压测
这个消息主要看产生消息和消费消息之间有没有良好的循环，比如，产生的快，消费慢。产生慢，消费快。主要看有没有消息积压。
这个消息的产生可用利用接口脚本来模拟，但是产生消息的数据量也要根据业务量来计算
二，前端性能测试
1，与哪些因素有关
CSS样式，HTML代码
2，视频切片
有些视频大，加载慢。需把一个视频切割成小的视频片加载
3，后端调用高频接口用随机错开
有些业务场景会在某个业务量，一起并发请求后端接口时，可能利用30秒内产生的随机数，进行间隔调用，规避一下大量请求导致后端接口承压过载