性能测试xx问

1、并发数怎么定？
一般不会直接设定并发数，而是根据业务量级去反推真实压力，可以参考日活规模、峰值在线比例、核心行为集中度等数据。
举例：有10万人在线，但在操作下单的用户为2万，我们要验证的是能不能扛住2万的“有效行为洪峰”，而不是10万人在线，这也就是通常说的“业务并发”，而不是技术并发。
系统的性能由TPS决定，跟并发用户数没多大关系
系统的TPS是一定的（在一定范围内），但并发用户数不一定，是可以调整的
通常大型系统1-5W并发，中小型5000并发

2、发现过的性能瓶颈？
遇到的瓶颈，很多不是系统资源，而是业务设计问题，比如缓存失效导致DB夜里放大、锁竞争、同步流程过长导致RT堆积（大量请求/响应时间变长、排队、延迟response time）、线程设置不合理等
我们不能只关注系统是否扛得住，更要关注“业务路径设计是否合理”，从系统视角，而不仅仅从技术视角去看问题。

3、性能测试的价值？
核心价值，不是找系统极限，而是识别业务增长下的风险拐点，它是业务安全工作，而不是技术工作。

4、如何定位性能问题？
一般从业务异常入手，然后去对齐数据库状态、连接池情况等业务层面，然后再看系统指标，一步步反向推理溯源，一轮轮试探，也可以充分利用日志进行分析。

5、VUE和TPS如何获取？
Vu用户数获取
已有系统：高峰时刻，一定时间内（如半个小时）的在线用户数10%
新系统：业务部门评估
TPS获取
已有系统：高峰时刻，一定时间内（如3-10分钟）的总业务量==>单位时间内完成的笔数2-5倍==>作为峰值的TPS
新系统：业务部门评估

6、有没有绝对的并发？
没有，两个进程的不同线程交替使用CPU，貌似在并行运行，但实际上：没有任何一个CPU可以做到在某一时刻同时运行两个进程（线程）。

7、性能测试关注点？
响应时间：服务器端的处理速度
服务端的资源使用情况
数据库端的资源使用请
系统的最大访问用户数量
系统的最大业务处理数量（核心业务）
系统能否支撑7*24小时运转
内存资源、线程资源能否正常回收
代码：算法、SQL语句
稳定性
可恢复性