国庆期间，公司安排了推广活动。在总公司的微信公众号进行推文，总公司的官方微信号称有1500万的粉丝数。上次由
于我们的大意，第一次在总公司公众号推文，巨大的流量直接把我们公司的主站搞崩了。所以，这次活动我们还是格外重视的。
为此，先整理测试方案和步骤。
- 制定详细压测计划
压测计划包括如下步骤:
1. 先分析目前生产环境，本次活动相关应用一周的运行情况。一周的内存使用率，一周的CPU使用率，同样还有硬盘和网络带宽的情况。（其实这里看均值是不太合理的，更合理的应该是直接看峰值）。
2. 基于1的结果，分析哪些机器需要进行性能升级，提前进行。
> 原因： 压测完成后，升级机器其实是需要流程和时间的，所以尽早确认的机器一定要提前升级掉。当然，这里评估哪些机器需要升级需要一定的经验。
3. 2完成以后，根据本次活动涉及的相关应用服务和升级后的生产配置，模拟搭建压测环境。如果条件允许，最好配置和生产一样。（阿里云支持购买一个月的机器服务）
4. 根据需求（保证用户）进行压力测试。根据压测环境的运行情况，评估生产环境的配置是否能抗受本次活动并发量？
1. 不能，需要做哪些升级？
2. 能，最大支持的并发为多少？（该数值需要**配置Nginx 限流**，避免流量超预期时系统崩溃）
- 压测
目的：分析保证用户友好体验前提下，我们能接受的最大并发流量。
工具，使用JMeter 工具进行压力测试。JMeter 基础的使用百度一下即可，但是基础使用可能无法满足我们的需求。比如压测环境的需求中，经常会要求你传入不同的参数。比如：不同的用户token、不同的手机号码等，这些参数每次请求的时候都要不一样，这个需要注意。详见《JMeter请求传入不同的参数》一文。
测试过程就不详细展开了，测试方法就是配置不同的线程数量。不断地增加线程数量，同时记录此时的聚合报告，最后分析在保证用户友好使用的前提下，能抗受的最大并发量。
我们的需求是保证3秒的接口响应耗时，我们评估下来支持最大并发为每秒190。
然后对比产品评估的流量峰值：1小时4W UP流量，所以PV为 10W。
- 兜底方案
两套兜底方案。
限流 + 崩溃页面（失效了）
- 过程中
1. 先分析整理计划。
2. 粗略评估本次机器
- 意外？
1. 兜底方案二崩溃页面失效。
2. MQ 是个好东西。
3. 遗漏渠道关联。(需求)
####
