2018年，我在广州上车了，在广州一手房遍地双合同时代的末期顺利入坑。。。在无奈和欣喜之中，总算把心安定了下来，还是印证了那句话：买房有时候真的需要冲动。
其实一直想写写有关故障处理方面的文章，互联网应用，都难免会因为人为或者不可抗的原因导致线上故障，只要业务在线上跑都有出现故障的风险，轻则只是其中某台机器down掉，实际对用户没有什么影响，重则可能整体服务不可用，影响大部分的用户。
说到内存分配，我们需要有一个常识性的认知：栈内存的分配较廉价，而堆内存分配相对昂贵。
很多时候，我们需要对应用进行弱网环境下的测试，验证应用在网络较差的情况下的表现。实现弱网环境搭建的方案有很多，本文介绍一种相对比较简单但非常好用的方案。
由于工作原因，需要对grpc协议进行压测，在网上找了ghz，但是它只是一个命令行工具并且不支持分布式，于是结合Locust+boomer实现了grpc协议的压测。
前言 2019年底，我加入了直播相关的业务团队，开始负责直播SDK和CDN转推相关的测试工作。其中我们直播SDK基本从0做起，完成从推流端到拉流端实现，所以我将会用直播系列文章记录整个的过程，当然，主要是以测试的角度。
Locust的性能缺陷
统计对象 从Runner通信机制那篇文章中我们知道有一个非常重要的消息类型——stats，这个是slave给master发送的消息，默认每3秒钟上报一次。stats消息的结构如下所示：
上一篇文章介绍了Locust的架构和核心类，那么接下来我们继续了解Locust分布式压测的核心：Runner的状态和通信机制。 我们知道Locust等压测工具支持分布式压测，就是说理论上可以通过不断添加压力机(worker)提高并发数量，这个机制让使用者可以自由地增减机器资源，从而达到期望的施压能力。