vlambda博客
学习文章列表

2.1 尽量模拟生产环境，模拟硬件比较难，可以等比模拟，比如生产是4台服务器，测试环境可以有2台服务器；模拟软件，尽量保证所有的软件版本位数都要一样；使用负载均衡模拟共享中心的应用

2.2 将服务器都放到同一个机房，这样可以最大限度避免网络问题，一般都会在同一个机房。

从图中可以看出最佳用户数，之后随着用户数的增加，资源利用率和吞吐量、响应时间趋于平稳，达到最大用户数时，资源利用率偏高、吞吐量下降、响应时间也在变大。

要进行多次负载测试和压力测试可能才能得出最佳用户数，不过也不是绝对的要结合业务和实际情况去得出最佳用户数。

  1、找出TPS每秒处理事务数、并发数（最佳用户数、最大用户数）、硬件相关指标（CPU、内存、磁盘、网络）

  2、分析用户使用行为，分析业务量，为估算做准备，比如双十一零点抢购等业务量爆发等用户行为；或者日常某些时间点用户业务量比较多等

  3、分析出测试点，要分析哪些业务要纳入性能测试范围，比如一个订票系统，订票就会比较容易发生集中购买的性能问题，就是找出系统中的哪个业务点是比较容易会用到并且会引发性能问题

1、跟产品、运营、开发沟通出性能需求，比如某个模块的响应时间要小于几秒，2-5-8是业界经理理论，2秒是快的，5秒是可以接受，8秒是难以忍受的。

2、与开发沟通系统的处理能力，资源占用率，数据库的访问量等

3、可以拿历史日志和同类产品的分析哪个时间段用户量业务量比较多，哪些业务用户用的比较多，一般系统都会有大数据埋点，通过大数据分析出用户的行为得出哪些业务在哪个时间段会比较集中

4、根据80/20原则进行估算处理能力-TPS每秒事务数：

采用80/20原则，80%业务会集中在20%的时间完成；

200万条/8个月/20天=1.25万条记录，计算出每天处理的数；

(1.25万条/8小时20%/3600)80%=1.736条记录，8小时*20%是一天中有20%的时间也就是1.6小时会集中处理业务，再除以3600计算出秒数，1.736就是每秒处理的条数；

5、要重点测试哪些模块呢，拿一个洗车业务举例：

• 用户常用功能，比如登录

• 数据流转复杂或者频繁的地方，比如购买洗车订单，查看洗车列表，到确认订单，到支付订单，

• 发生频率非常高，比如查看洗车列表，查看洗车价格

• 关键程度非常高，

• 资源占用非常严重，比如返回洗车列表，查询数据库

• 关键的接口，比如洗车列表排序、距离定位等接口