压测是准备大促过程当中相当重要的一个环节,在真正开始压测以前系统一般要作必定的改造,以使得压测请求的代码执行路径更符合实际状况,主要进行的改造和准备主要有以下内容缓存
对于压测服务中涉及到db(msyql、hbase、ob)的系统,在压测前须要联系DBA、PE先准备好所需的压测表。
对于缓存(tair、tbase)也须要进行压测缓存key和正式key区隔处理,能够和zcache同窗确认其是否支持,若是不支持,就须要本身实现。另外缓存中压测数据的过时时间能够设置的短些,可以知足压测的要求便可,以避免得压测数据占用过多的缓存空间,影响正常业务的缓存命中率(最好能经过drm推送的方式来修改)。异步
在不少系统中会使用线程池来执行异步操做或者是并行执行操做,而当前请求是否为压测请求的标识是在ThreadLocal中保存的,具体到sofa系统中是用AbstractLogContext来封装实现的。于是在进入到异步线程中时须要把当前请求的context传入到异步线程中,而且在异步线程中的执行中添加try finally语句块,在finally中须要把异步线程中context清除掉,以避免线程池下次执行时形成context 污染。线程
在进行压测时,所使用的压测数据是有限的,百万级别的就算是比较大了,而压测的请求量一般是每秒数万或数十万的量,于是会重复使用这些数据。对于会访问缓存的请求,当循环一轮后这些数据基本上都会在缓存中了,若是此时仍然持续压测,那基本上就只是压缓存了,而不能压到db操做和后续的do转model等操做了。设计
于是应当可以控制必定比例的请求的强制走db,这个比例值应当是能够动态调整的,经过调整这个比例也能够了解本身系统db的qps峰值、本身系统所有走db状况下服务的qps值。中间件
缓存命中率改造主要是针对读服务,目的是使得压测请求执行状况尽可能符合真实状况。对于写服务也须要作相似的改造。开发
大多数的写服务会进行幂等控制,会根据主键先到db中进行下查询,若是查询到数据,就再也不写入db了,于是在进行写服务压测时,也须要进行适当的改造,以使得请求更符合真实状况,主要的改造有两种方式:mock
在大促中还有一种状况是大促时执行的链路和平常的链路是不一样的,对于链路的切换也须要添加对应的控制,可以经过推送配置进行切换。
更精确的控制的是压测时进行的链路切换只针对压测请求生效而不对正常请求生效,在大促期间的链路切换对平常请求生效。要实现这样的控制,在代码的实现层面须要好好的设计,一方面要知足功能的实现,一方面还要具有良好的可读性,减小后续的维护成本。随机数
前面提到的都是正常的压测,这些压测所采用的数据都是经过必定的规则mock出来的,可是对于有些特殊的场景,是不能用随意mock出来的数据的,这时就必须把线上已有的数据或者请求录制起来,经过重放的形式进行压测。配置
这种状况会变得特别复杂,须要开发特别的系统或者对已有的中间件进行改造才能够实现。date