大促前先压一次，压出来的是什么

一、活动当天先出问题的是哪一步

举个例子：一家卖年货的小店，春节前做了一场秒杀。宣传发出去那天上午十点，页面打开正常，付款那一步开始转圈。

回头看，慢的不是页面，是下单之后那一串动作：查库存、算一遍优惠、写订单、发通知。

这一串动作每个客户都要走一遍。人少的时候看不出问题，人一多就开始排队。

压测，就是提前把活动那天的流量造出来，让系统在没有真客户的情况先跑一遍。它要回答的就是这一问：这一串动作，最多同时接住几个人。

二、带回来的不是一个数，是三件事

第一件，最多同时接住多少订单，超过这条线以后出错是什么样子。

第二件，先扛不住的是哪一处，是应用进程、数据库，还是外面那一家服务。

第三件，出错那天要做什么动作，先关秒杀入口还是先停掉不重要的功能。

只带回来一个人数，活动当天还是不知道该按哪个开关。

三、先定动作，再定流量

不要一上来就说模拟十万次访问。先把客户那天最常做的三个动作写下来。

一般是看商品、下单、付款。每个动作背后要查几次、写哪几张表，团队里要有人说得清。

有了动作，流量才有意义。同样是一千次点击，全落在下单和全落在看页面，结果差得很远。

四、压到出错，还是压到计划人数

两种做法各有各的用处。

压到出错，想知道上限在哪、错的样子是什么。这一种要单独一套环境，不能在线上跑。

压到计划人数，想验证那一个具体方案撑不撑得住。预估五千人同时下单，就按七千人的量压一次，看有没有排队。

先做后一种，再补前一种。后一种回答这次活动能不能开，前一种回答以后能开多大。

五、数据量不一样，结果就不一样

测试库里只有几百件商品，线上是几十万行订单。同一句查询，数据少的时候很快，数据多了就慢下来。

压测环境的数据量要贴近线上，至少把那几张活动会碰到的表填到接近真实的行数。

行数对不上，压出来的数只能当参考，不能当结论。

那家小店后来把订单表填到和线上一样的行数，同一次压测接住的人数少了一半还多。

六、外面那一步要不要一起压

下单要扣库存、要算优惠、可能要发一条通知，这些动作常常交给外面的服务。

压测时那一步如果直接回成功，你压的只是自己这一半。活动当天卡住的，常常是没压的那一半。

做法有两种：请对方配合走一场带真实回应的压测；或者在自己这一侧把对方的响应时间照实模拟出来，连它慢和失败的那两种样子一起模拟。

哪些是真的、哪些是照样子造的，要写在纸上。

那家小店第二次压测才把收款那一步一起放进去，慢的地方正好落在付款回来写订单的那一处。

七、压测环境和线上差在哪

最容易差三样：机器台数、数据量、还有那道限制并发人数的设置。

线上开了限制，压测环境没开，上限就会被高估。

线上用几台机器分摊，压测用一台大机器，压力落在哪里就不一样。

对不上的地方一条条列出来，标一句它会让结果偏大还是偏小。这一张纸比压测报告更有用。

八、造流量时不要带上客户的信息

压测要造大量请求，最容易顺手拿线上那一份数据改一改。

要分清用的是信息还是量。订单结构、商品、金额可以照抄，姓名、手机号、地址不要带进压测环境。

一般做法是按真实的分布造一批假数据，条数一样，内容不属于任何真人。

确实需要带真实数据时，按测试环境用生产数据那一条规矩走：谁批准、留多久、用完怎么处理。

九、压出来的数落到哪几个决定

第一，活动分几档放量，每一档放多少人，到了上限就停。

第二，哪几个功能在那一天暂时关掉。查历史订单、导出报表这类，不关就来抢资源。

第三，值班当天盯哪一个数。盯的应该是下单那一串动作排队排到了多少人，不是页面被打开多少次。

三个决定写进同一份活动安排里，让做投放和做客服的人都看得到。

十、流量超了先挡谁

提前定好顺序，比现场商量快得多。

顺序一般这样排：先把不重要的功能关掉，再把下单入口改成排队，最后才整站暂停。

排队那一档要想清楚客户看到什么。转圈又没有进度，人就反复点，反复点让压力更大。

给一句明确的话：前面还有多少人、大概要等多久。说不准就不要编一个数，只说正在排队，请别反复提交。

十一、压完要留哪几样

三样要留下：这一次的条件、这一次的结果、下一次要改的三件事。

条件要写清用了多少行数据、几台机器、哪一步是模拟的。隔一个月再看，说不清条件就等于没压过。

结果不要只留最好看的那一版，把出错的那一版一起留着。

下一次要改的事，要写上一个明确的人和完成时间。

十二、小团队做得起的做法

不必先买专门的压测平台。先手写三个动作的脚本，凑出几十人的并发，跑一次看哪里先报错。

这一步的价值不在数字准不准，在于团队第一次看见下单那一串动作的真实形状。

那家小店用的就是这一式：两个人各写一个下单脚本，先跑出五十人的并发，看哪里先报错。

跑通了再往上加人数，再把数据量和那道并发限制补成和线上一致。

一年认真压两次的团队，比买了平台从没跑过的团队离事故更远。

十三、什么时候要再压一次

上一次的结论不是长期有效的。四种变化以后要重来一遍：换过机器规格、动过下单那串动作里的任何一步、加过或者去掉过一层存结果的中间件、换过外面那一家服务。

哪怕什么都没改，一年里也要按最大的一次活动量再压一遍，看看这一年攒下来的数据会不会让它变慢。

再压一次的成本比第一次低。脚本还在，条件那张纸还在，改几个数字就能跑。

十四、先做哪一步最要紧

先把下单这一串动作写清楚：调了哪几处、每一处大概多久返回、返回不了会怎样。

有了这张纸，压测才知道该造什么流量；没有这张纸，压测只能在页面外面绕圈。

活动前压一次，压出来的不是那个好看的人数，是当天要按的那几个开关。