From e089b9c847dcac350febae3410e814134ecc7d70 Mon Sep 17 00:00:00 2001
From: Xargin <cao1988228@163.com>
Date: Sat, 16 Jun 2018 14:47:36 +0800
Subject: [PATCH] update rl

---
 ch5-web/ch5-06-ratelimit.md | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/ch5-web/ch5-06-ratelimit.md b/ch5-web/ch5-06-ratelimit.md
index 14d7546..ae80a75 100644
--- a/ch5-web/ch5-06-ratelimit.md
+++ b/ch5-web/ch5-06-ratelimit.md
@@ -84,3 +84,22 @@ Transfer/sec:      5.51MB
 多次测试的结果在 4w 左右的 QPS浮动，响应时间最多也就是 40ms 左右，对于一个 web 程序来说，这已经是很不错的成绩了。这还只是家用 PC，线上服务器大多都是 24 核心起，32G 内存+，CPU 基本都是 Intel I7。所以同样的程序在服务器上运行会得到更好的结果。
 
 真实环境的程序要比我们这里的 `hello world` 复杂得多，有些程序偏 IO bound，例如一些 proxy 服务、存储服务、缓存服务；有些程序偏 CPU/GPU bound，例如登陆校验服务、图像处理服务。不同的程序瓶颈会体现在不同的地方，这里提到的这些功能单一的服务相对来说还算容易分析。如果碰到业务逻辑复杂代码量巨大的模块，其瓶颈并不是三下五除二可以推测出来的，还是需要我们拿真实的环境来进行压力测试。
+
+对于 IO bound 类的程序，其表现是网卡/磁盘 IO 会先于 CPU 打满，这种情况即使优化 CPU 的使用也不能提高整个系统的吞吐量，可能只能提高磁盘的读写速度，增加内容大小，或者提升网卡的带宽。而 CPU bound 类的程序，则是在存储和网卡未打满之前 CPU 占用率提前到达 100%。
+
+无论哪种类型的服务，在资源使用到尽头的时候等待着用户的都是请求堆积，超时，系统 hang 死，而最终伤害到终端用户。对于 web 服务来说，瓶颈不一定总是在系统内部，也有可能在外部。非计算密集型的系统往往会在关系型数据库环节失守，而这时候 web 模块本身还远远未达到瓶颈。
+
+先来看一个计算密集型服务的例子：
+
+```go
+```
+
+再来看一个 IO bound 服务的例子：
+
+```go
+```
+
+再来看一个外部存储系统瓶颈导致瓶颈的例子：
+
+```go
+```
\ No newline at end of file