压测 1

• 服务器为 8 核 16g，使用 puma 开启 15 个 wokers
• 每秒 200 请求压测 重度使用 mysql 的 api 接口

总结：

1. 平均每个请求的时间都要 1.6s 以上，apdex 得分非常的低
2. ruby 占用时间为 60% 左右，mysql 占了将近 40%。
3. 尝试通过提升服务器的配置性能到 12 核，puma 开多几个实例。效率还是很低，并没有与提升的配置成正比。

压测 2

• 在上一个压测中，ruby 占用的时间实在太多了，又没有解决思路，决定转变下压测条件。
• 使用 nginx 做负载均衡，性能好的服务器 weight 为 2，另一个 weight 为 1。
• 每一台服务器为 4 核 8g，使用 puma 开启 8 个 wokers
• 第二台服务器为 2 核 4g，使用 puma 开启 5 个 wokers
• 每秒 200 请求压测 重度使用 mysql 的 api 接口

总结：

1. 效率明显上升，apdex 得分看起来不错了
2. 虽然效率上升了，但是 ruby 占用时间还是很高 (这个需要继续探索)
3. 在服务器的配置 比 压测 1 的服务器配置差的情况下，既然效率会更高。这是负载均衡的功劳了，成功让对单台服务器的并发降了下来。
4. 并发越高，服务器性能越差 (参考下面第二张图)。 * * *

压测 3

• 分析代码后，代码并没有可疑之处。可是为什么 ruby 占用时间那么高呢？
• 怀疑是在什么地方排队等候，花了时间。
• 在等 mysql？redis?
• rails 中 mysql 默认连接池为 5，尝试压测不同数据的连接池。
• 为减少影响，使用单台服务器 服务器为 4 核 8g，使用 puma 开启 8 个 wokers

总结：

1. 5pool 的条件下：ruby 花费了 60% 的时间。
2. 提升了 pool 之后：ruby 花费的时间降下来了，花了 20% 左右。
3. 原来 ruby 花费了大部分的时间，是在等待 mysql 的连接池啊。
4. 现在是 mysql 占用大部分的时间了，可以专心的优化 sql 之类的了

追加

• 之后尝试使用 gem 'connection_pool' 为 redis_store 增加了连接池，增加后没有什么变化。