如何自己对网站进行压力测试并了解其何时会崩溃
想象一下企业主典型的噩梦：你为顶级网红的大型广告活动拨款了 500 万卢布。流量涌入，订单理应创下纪录。然而，你没有迎来大量客户，而是收到了一连串愤怒的信息。你原本的在线商店变成了一个显示着“503 Service Unavailable”或“502 Bad Gateway”的白屏页面。预算烧光了，声誉受损，客户流失到了竞争对手那里。
为了避免这种情况发生，你需要提前了解你资源的承受极限。在本文中，NineLab 的工程师详细解释了什么是负载测试，为什么网站会“崩溃”，以及如何自己运行基础的压力测试。
什么是压力测试，它与负载测试有何不同？
许多人混淆了这两个概念：
- 负载测试 (Load Testing): 我们检查网站如何处理预期数量的用户。例如，我们知道在黑色星期五每小时会有 5000 人访问，我们就观察是否会出现任何速度下降。
- 压力测试 (Stress Testing): 我们刻意用流量“淹没”网站，直到它崩溃。我们的目标是找到那个故障点（瓶颈），确切地查看系统是如何“死掉”的（更重要的是，之后它恢复得多快）。
重要规则： 永远不要在高峰时段对生产 (production) 数据库进行压力测试。最理想的做法是为测试部署一个环境与您网站完全一样的副本（Staging环境）。
为什么网站还是会崩溃？3 个架构瓶颈
企业往往认为网站崩溃是因为“服务器容量不够”或“内存太少”。但在实践中，90% 的问题根源藏得更深：
- 数据库无法处理队列 (Locks): 十个用户同时尝试生成购物车。数据库开始锁定记录以避免冲突。第十一个用户排队等待并超时掉线。
- Web 服务器连接数达到上限: 您的 Nginx 或 Apache 被配置为同时处理 500 个连接（最大工作线程）。第 501 个用户根本无法建立连接，并会收到 502 或 504 错误。
- 缺乏缓存: 当 10,000 人访问主页时，服务器每次都必须从数据库重新请求菜单、产品目录和价格来生成页面。这能在几秒钟内将 CPU 负载拉满至 100%。
自己动手进行测试的工具
如果你只想对可靠性有一个大概的了解，你不必是一名的 DevOps 工程师（查阅我们关于应该使用哪些监控指标的指南）。现有多种简单的实用程序及云端服务可用来生成合成负载。
1. k6 Cloud / Grafana k6
Grafana Labs 提供的最现代的工具之一。基础测试脚本用 JavaScript 编写。该服务带有云版本（允许模拟全球用户的真实分布）并且可以为您生成有关响应时间和故障等相关清晰易懂的美观图表，非常方便。
2. Apache Benchmark (ab)
与 Apache Web 服务器关联的经典控制台工具。非常适合快速和粗略的检查。由于其极高的普及度，在 MacOS 或是 Linux (Ubuntu) 环境下这通常已在系统中默认安装好了。
ab -n 1000 -c 100 https://vash-sayt.ru/其中，-n 1000是总请求数量，而 -c 100 是同时进行连接的数量。
在这个生成的报告中，我们首先主要关注这些主要指标参数:
- Failed requests (失败的请求): 如果该值不是零，就说明你得服务器甚至没有撑过这次这点轻量的流量。
- Requests per second (RPS): 您的服务器能够实现每秒真实的提供查询的次数。
3. Yandex.Tank
来自 Yandex 更具杀伤力的一种重量级武器。这款功能异常强大的工具能处理各种极重的高负载体系聚合及各种百分位数统计反馈报告输出。然而它的完美精细优化调节需要你具备有一定的基础代码及结构处理维护测试专家等级的技术。
自行压力测试中的三个致命错误
如果您决定自己着手处理问题，请特别当心陷入这类使之前的所有检验测试完全变成是无用功的错误诱惑陷阱之中:
- 仅测试静态的那些单一基本网页界面: 对主页的或往期较久某文章的内容信息页执行这些压力分析和运行模拟负荷是毫无意义可言的。
- 只对本地某个单一点网络位置上开火猛攻: 假借自身用这办公无线 Wi-Fi网络运行对该企业产品发起执行本地高频大量流量剧烈压力行为冲击命令脚本。其实在这情景中受折腾体验受阻上限仅仅只不过仅仅体现了你们公司的无线终端路由器以及互联网运营商那单薄脆弱带传输线网口能力水平而已并不能证明测试服务端的能力。而一次符合正规的标准高强压网络载体必须通过运用分散和分布式大数量并机云集服务处理器组合来进行的。
- 直接忽视各种应用情境情况与用户动线情况模拟 (User Flow). 正常的购买者其实不可能真的就会每秒进入一次或是一手点击上万回的访问进你的网页里。人们平时真实的状态都是：打开某个目录后，他会在该分类相关商品介绍界面上逗留大概得30秒看图片查基本资料等之后然后再点入，跟着之后再最后添加到这购物车里。
关于最终的结果分析：下一步应该作何对策呢？
您成功运作发起了针对这项目程序系统强劲流量压力，紧接着屏幕报出一个严重警告失效提示画面，整个页面和网挂了直接垮掉。那么这时该接这着怎么做？
所谓的这自测结果充其量仅仅只是解答了一个关于 “我们会被冲垮压死掉么？”的问题罢了。这种办法绝对也是不可能解决关于 “我们当时究竟是什么原因导致其突然中断垮台” 还有更关键的是“我们将该怎么彻底解决掉和排除去修补他？
假如果真是整个信息产品构建框架都在极大量的访客冲击之中当场彻底陷入停顿乃至土崩瓦解崩溃时，但这确事实上这也根本并不真的意味和等同这你现在必须要紧急立刻花费每月大几十万去强行续购那些最高档豪华的最顶配套高性能的硬实力强服务器硬件的投入！也许极有可能是你只不过急切需要现在仅仅架设或配置起来一套基于 Redis 框架系统来为数据处理统计筛选合并等做好优化的高级聚合缓存加速。更有可能仅仅只是因为某一行极其中极糟糕的代码的拉跨写法的某一条超级沉长缓慢处理能力的查询 SQL 原语句阻塞了该相关所全部其他连接信息交互运转导致了牵连挂起表单死锁瘫痪。
对于想要实现并建立更大格局的高负荷企业理想雄心壮志规划来讲 ——去尝试大举动地重新拆解重构当前这类严重拖拉老旧落后陈旧繁冗复杂沉甸厚重的全盘一体整体的庞大系统单体框架设计,，借机将这类单块式的老大难应用通过将其结构转化，积极的引入导入与建立各种全新的云端化 微服务化(microservice）加配配合各种最新的智能多节点的集群载抗高压的 各类先进 高能效 的网路负载协调平衡装置(load balancer) 等（就像我们的高负载推荐系统案例中那样）。
NineLab 重点并致力于深入且针对各种能够高效且极可靠的避免以及预防产生导致停机灾难，全力保证网络服务高度的高可生存持续有效能力 (high-load容错高承架构设施项目研发和设计部署！当然我们也并不仅仅是就单单只限于朝您的该网站进行那些粗狂盲目的机器人物理的无脑狂丢发报文和网络假数据的疯狂扫射和单纯访问。我们在整体和全局层面我们将展开全面并执行最极致的各类深入到底层结构最深处去进行的每一个关键节点的各项极为细小的那些可能潜在卡顿问题引发的技术瓶颈深度检测评估，帮你在构建设立那些实现能横跨广域并向各类多个区域的云平台多网进行全局布置分散布点式服务网络集群规划组合，帮助调整您的相关核心重要各环节功能组件使之发挥功效，使得你这款耗费巨资打造的核心重要商业心血结晶不仅可以足以承受并在面对任何那些甚至是突然具有不可预估超可怕爆发力的各种高度疯转流传传播级别的市场推广营销等突发活动来袭时都显得坚如磐石不倒。请联系我们的技术工程师团队获取帮助。
主题常见问题
流量形态与数据往往与生产不一致。需要场景、与线上一致的指标，以及可回滚的逐步加压。
常见瓶颈在数据库与执行计划、连接池、同步外部调用与队列——可作为快速排查清单。
不一定：失效、冷启动与热点键可能适得其反。缓存要按读模型与 SLO 设计。
垂直扩展与查询优化触顶，且数据增长在分片键上可预期时。