quakewang

好像发现 ruby china 的一个 bug

quakewang — Sat, 20 Mar 2021 15:54:19 +0800

点击一个会导致 404 的页面，比如这个链接

然后点页面上的其他链接，也无法跳转了

性能优化案例分析之二：时间区域查询的性能优化

quakewang — Tue, 14 Nov 2017 11:19:13 +0800

背景

我们在项目中经常会遇到把事件显示在日历上的需求，在项目管理，事件追踪，预约等相关功能中很常见，界面通常类似这样：

常见的做法是给对应表添加开始时间和结束时间的栏位：start_time and end_time，然后构建一个查询得到这个时间段内的数据，示意如下：

            |---给定时间段---|
|---A---| |---B---|  |-C-|   |---D---|

查询要排除掉 A 和 D 这种数据，也就是结束时间小于给定的开始时间，或者开始时间大于给定的结束时间：not (end_time <= :start or start_time >= :end)

从 NOT (A OR B) 可以得到 (NOT A) AND (NOT B)，最终的查询语句是这样：

select * from events where end_time > :start and start_time < :end

考虑到这是一个范围查找，通常都会给这 2 个栏位加上索引，数据量小的时候，这个查询效率很高，但在数据增加到百万级别之后，在慢查询日志里面经常会发现这个查询耗时超过几百毫秒，随着数据量的增加，甚至超过 3000 毫秒。

分析过程

继续用慢查询的分析过程套路

第一步：EXPLAIN

有时候相同的查询语句，只是查询参数少许不同，会导致预估的 IO Cost 不同，执行计划也会改变，我们可以看到，这个查询有时候会用 start_time 的索引，有时候会用 end_time 的索引：

explain select * from events where end_time > '2017-05-01 00:00:00' and start_time < '2017-06-01 00:00:00'\G

  select_type: SIMPLE
        table: events
   partitions: NULL
         type: range
possible_keys: index_events_on_start_time,index_events_on_end_time
          key: index_events_on_start_time
      key_len: 5
          ref: NULL
         rows: 799704
     filtered: 50.00
        Extra: Using index condition; Using where; Using MRR


explain select * from events where end_time > '2017-08-01 14:00:00' and start_time < '2017-09-01 00:00:00'\G

  select_type: SIMPLE
        table: events
   partitions: NULL
         type: range
possible_keys: index_events_on_start_time,index_events_on_end_time
          key: index_events_on_end_time
      key_len: 5
          ref: NULL
         rows: 946430
     filtered: 50.00
        Extra: Using index condition; Using where; Using MRR

第二步：理解执行计划

从执行计划其实已经可以看到这个慢查询的原因：需要检查的行数太多了，预估在 79 万和 94 万。但保险起见，还是从INFORMATION_SCHEMA.OPTIMIZER_TRACE表中获取信息来确认我们的猜测：

{
  "index": "index_events_on_start_time",
  "ranges": [
    "start_time < 0x999d02f000"
  ],
  "rows": 3147211,
  "cost": 2.73e6,
  "chosen": false
},
{
  "index": "index_events_on_end_time",
  "ranges": [
    "0x999d02e000 < end_time"
  ],
  "rows": 946430,
  "cost": 826083,
  "chosen": true
}

这个查询相当于构建了 无穷小 <= start_time <= ? 和 ? <= end_time <= 无穷大 这样 2 个开放区间查询。在这里由于前者的开放区间内有超过 300 万的数据需要检查，所以执行计划选择了后者相对比较小的 94 万作为索引。

第三步：分析数据

这个表有超过 600 万的数据：

show table status like 'events'\G

           Name: events
         Engine: InnoDB
           Rows: 6294423

所有的数据开始时间和结束时间均匀分布，索引也没有问题，而且查询除了按月，也有按其他维度（天，日，小时，指定范围）来进行查询，通过添加辅助字段也无法减少开放区间的查询数据量，好像进入了一个死胡同...

解决方案

遇到现有知识无法解决的问题，那就 Google 吧，经过尝试不同的关键字（关于如何选择关键字解决日常搬砖遇到的问题，可以留个坑，以后再写）发现了一篇很详细的文章，和我们遇到的情况是一模一样： https://explainextended.com/2009/07/01/overlapping-ranges-mysql/

文章提到了将时间区间变成二维线段，然后利用 R-Tree (spatial) 索引，通过范围重叠来解决这个性能问题。看起来很不错，那就开动吧。

添加一个辅助字段并添加索引：

alter table events add column time_range linestring;
create spatial index index_events_on_time_range on events(time_range);

然后把时间区间转换成线段更新到这个字段：

update events set time_range = LineString(Point(-1, UNIX_TIMESTAMP(start_time)), Point(1,UNIX_TIMESTAMP(end_time)));

用 MBRIntersects 函数来查询重叠：

select * from events where MBRIntersects(time_range, LineString(Point(0, UNIX_TIMESTAMP('2017-08-01 00:00:00')), Point(0, UNIX_TIMESTAMP('2017-09-01 00:00:00'))));

80 毫秒！相同的查询之前需要 2410 毫秒：

select * from events where end_time >= '2017-07-01 00:00:00' and start_time <= '2017-08-01 00:00:00';

给数据库再加个 trigger，当更新和插入数据时，自动更新 time_range 这个字段：

CREATE TRIGGER events_insert_time_range BEFORE INSERT ON events
FOR EACH ROW
BEGIN
  SET NEW.time_range = LineString(Point(-1, UNIX_TIMESTAMP(NEW.start_time)), Point(1, UNIX_TIMESTAMP(NEW.end_time)));
END

CREATE TRIGGER events_update_time_range BEFORE UPDATE ON events
FOR EACH ROW
BEGIN
  IF ((NEW.start_time != OLD.start_time) OR (NEW.end_time != OLD.end_time)) THEN
    SET NEW.date_range = LineString(Point(-1, UNIX_TIMESTAMP(NEW.start_time)), Point(1, UNIX_TIMESTAMP(NEW.end_time)));
  END IF;
END

问题解决收工！

扩展

这个问题有很多可以扩展的问题：

我们之前只会将 R-Tree 用在地理位置的查询，从这个问题可以扩展到时间，IP 地址等其他类似的查询，除了这些范围查询还有其他适合应用的场景吗？

文章中构建的线段是 (-1,start_time) 到 (1,end_time) 的一条斜线，用位于 X 等于 0 的线段去查询重叠。为什么不能用更直观的方式（类似文章开头的线段示意图），构建一个 (start_time, 0) 到 (end_time,0) 一条线段，然后用 Y 等于 0 的线段去查询重叠呢？

如果不用数据库 trigger，在 rails 里面有什么方法能够自动更新这个辅助字段呢？甚至更进一步，是否可以删除掉 start_time 和 end_time 这 2 个字段，只用 time_range 这一个字段来满足所有的查询需求呢？

下篇占坑性能优化案例分析之三：N:M 的用户动态优化

性能优化案例分析之一：软删除是慢查询的罪魁祸首？

quakewang — Wed, 08 Nov 2017 20:20:34 +0800

背景

在 Rails 项目里面，为了实现软删除，我们经常会使用 acts_as_paranoid 这个 gem。它会给数据库表添加一个 deleted_at 栏位，当删除数据时给这个栏位设置当前时间，查询数据时由于设置了 default_scope，会自动添加deleted_at is null的查询过滤这些数据，从而实现软删除。这个 gem 由于设置简单，使用方便，被用在很多项目中。

在给某个使用了这个 gem 的项目做性能优化时，发现很多类似这样的慢查询，平均执行时间超过 2000 毫秒：

select * from articles where id in (?, ?, ?, ...) and deleted_at is null;

分析过程

对于所有 Mysql 慢查询的分析过程都是类似的

第一步：EXPLAIN

explain select * from articles where id in (?, ?, ?, ...) and deleted_at is null\G;

得到了如下的输出：

  select_type: SIMPLE
        table: articles
   partitions: NULL
         type: ref
possible_keys: PRIMARY,index_articles_on_deleted_at
          key: index_articles_on_deleted_at
      key_len: 6
          ref: const
         rows: 9
     filtered: 0.50
        Extra: Using index condition

第二步：理解执行计划

从输出的possible_keys和key里面可以看到，这个查询有 2 个可能的索引可利用：主键索引和辅助索引，但是最终选择了辅助索引index_articles_on_deleted_at，和我们设想要用的主键索引PRIMARY有出入。为了进一步理解 mysql 为什么选择这样一个执行计划，可以把执行计划优化器的追踪参数打开，再次执行扩展分析计划，然后从INFORMATION_SCHEMA.OPTIMIZER_TRACE表中获取详细信息：

set optimizer_trace="enabled=on";
explain EXTENDED select * from articles where id in (?, ?, ?, ...) and deleted_at is null;
select * from INFORMATION_SCHEMA.OPTIMIZER_TRACE\G;

在输出里有这样一段，Mysql 认为使用辅助索引的 IO 花销 16.8，比主键索引的花销 19.666 低，所以最终选择了这个辅助索引：

"considered_access_paths": [
  {
    "access_type": "ref",
    "index": "index_articles_on_deleted_at",
    "rows": 14,
    "cost": 16.8,
    "chosen": true
  },
  {
    "rows_to_scan": 14,
    "access_type": "range",
    "range_details": {
      "used_index": "PRIMARY"
    },
    "resulting_rows": 1.4,
    "cost": 19.666,
    "chosen": false
  }
]

第三步：分析数据

查看数据表的状态和索引状态：

show table status like 'articles'\G;

           Name: articles
         Engine: InnoDB
        Version: 10
     Row_format: Dynamic
           Rows: 3122573

show index from articles where key_name = 'index_articles_on_deleted_at'\G;

        Table: articles
   Non_unique: 1
     Key_name: index_articles_on_deleted_at
 Seq_in_index: 1
  Column_name: deleted_at
    Collation: A
  Cardinality: 122621

这个表有超过 300 万的数据，虽然辅助索引的分组看起来有 122621 那么多，但是都是对删除时间不同的索引，而实际大部分数据都是 NULL，所以这个查询完全利用不到辅助索引优势，导致 Mysql 预估的执行计划 cost 和实际相比有天壤之别。

解决方案

很简单，删除这个索引就好了，这个索引是acts_as_paranoid文档中推荐创建的，但是实际上大部分的数据模型都不需要建立这个索引，如果说它是罪魁祸首，也勉强说得过去。

扩展

虽然这个性能问题看起来很简单，但是每个简单问题背后都有很多更深入问题。如果从INFORMATION_SCHEMA.OPTIMIZER_TRACE表中完整信息开始研究，我们会发现这个问题的根源在于 Mysql 5.6.9 之后引入的 optimizer_switch use_index_extensions，更进一步了解会发现辅助索引和主键索引同为 B+TREE，为什么会有不同的查询 cost 呢？

再扩展一下，如果这个问题不是在 deleted_at 这种类型的索引上，而是发生在其他栏位上，比如这样的慢查询：

select * from articles where id in (?, ?, ?, ...) and score > 85;

那是否可以通过 Cardinality 和 Rows 来判断有必要给 score 加索引呢，解决方案是否会不一样呢？

除了删除索引以外，我们还可以用 mysql 语句force index来强制指定查询使用主键索引，在 rails 里面如何方便地强制索引呢？

除了添加 deleted_at 这种标志位的方法以外，还没有其他方法实现软删除呢？相比较的优缺点是什么？

如果以上这些问题你都能回答了，恭喜你，EXP++，LV UP :)

下篇占坑性能优化案例分析之二：时间区域查询的性能优化

counter_cache + foreign_key + MySQL = DEADLOCK??

quakewang — Thu, 15 Jun 2017 14:58:27 +0800

最近在检查一个项目的日志时，发现了一些奇怪的 deadlock 错误，经过排查之后发现和 counter_cache 以及 foreign_key 相关，记录一下相关的情况。

功能需求：用户可以对一篇文章点赞，文章需要显示共有多少个赞。为了性能考虑，在 belongs_to 里面设置了 counter_cache，这是很常见的做法。简化后的 model 代码如下：

class Article < ApplicationRecord
  has_many :likes
end

class Like < ApplicationRecord
  belongs_to :article, counter_cache: true
end

migration 脚本如下，为了数据一致性考虑，利用了数据库的外键约束，设置了 foreign_key：

class CreateArticles < ActiveRecord::Migration[5.0]
  def change
    create_table :articles do |t|
      t.string :title
      t.text :content
      t.integer :likes_count, default: 0
      t.timestamps
    end
  end
end

class CreateLikes < ActiveRecord::Migration[5.0]
  def change
    create_table :likes, force: true do |t|
      t.references :article, foreign_key: true
      t.timestamps
    end
  end
end

日志显示，当多个用户同时对同一篇文章点赞的时候，有概率出现死锁，在 console 里面用多线程模拟一下并发点赞：

3.times.map {
  Thread.new {
    Like.create(article: Article.find(1))
  }
}.each(&:join)

跑几次就很容易重现出这个错误：

ActiveRecord::StatementInvalid: Mysql2::Error: Deadlock found when trying to get lock; try restarting transaction: UPDATE `articles` SET `likes_count` = COALESCE(`likes_count`, 0) + 1 WHERE `articles`.`id` = 1

一开始我很不理解为什么这里会出现死锁，因为 Like.create 产生的 sql 很简单：

INSERT INTO `likes` (`article_id`, `created_at`, `updated_at`) VALUES (1, '2017-06-15 06:10:48', '2017-06-15 06:10:48')
UPDATE `articles` SET `likes_count` = COALESCE(`likes_count`, 0) + 1 WHERE `articles`.`id` = 1

按照我原先对 mysql 的理解，只有第二句执行 update 的时候，才会对 Article 表的 id 1 记录请求一个 exclusive (X) lock，每个线程都只有一个锁的情况下，只会出现 lockwait，而不是 deadlock。

经过搜索相关关键字，发现了这个 bug 报告： https://bugs.mysql.com/bug.php?id=48652

原来由于外键的存在，在执行第一句 insert 的时候，会对 Article 表的 id 1 记录请求一个 shared (S) lock：

If a FOREIGN KEY constraint is defined on a table, any insert, update, or delete that requires the constraint condition to be checked sets shared record-level locks on the records that it looks at to check the constraint. InnoDB also sets these locks in the case where the constraint fails.

2 个线程的 SQL 执行顺序按照这样的时序发生，就会产生死锁：

T1  INSERT 获得 S lock （Article id 1记录）
T2  INSERT 获得 S lock （Article id 1记录）
T1  UPDATE 升级 X lock (等待T2的S lock释放)
T2  UPDATE 升级 X lock (等待T1的S lock释放，死锁发生)

那如何解决这个问题？有几个选择：

A. 取消外键

如果能够在代码层面保证数据一致性，取消外键是最简单的选择。

B. 改用 postgresql

对于新系统，我现在都强烈推荐 postgresql，用过了你就不会想回去 mysql。这个外键导致死锁的问题在 9.3 版本之前也存在，但是很快通过新的 Lock 类型解决了，看看 mysql 的那个 bug 报告日期，我都要哭了。

C. 不用 ActiveRecord 的 counter cache callback

如果我们能够将 update counter 的语句在 insert 之前执行，也就不会有死锁的情况发生，改进一下 model 代码如下：

class Like < ApplicationRecord
  belongs_to :article

  before_create do
    article.increment!(:likes_count)
  end
end

题外话，如果相关模型的并发写很高，即使在没有外键或者 postgresql 的情况下，更新 counter cache 也会成为一个瓶颈，我们还可以选择将计数器更新用 redis 做 buffer，每 N 次再同步到数据库。

Ruby 2.4 哈希表 (Hash) 的变化

quakewang — Thu, 16 Mar 2017 14:50:06 +0800

Ruby 2.4 对哈希表引入了一些性能改进，这些变化是 Vladimir Makarov 在 2016 年初向 Ruby Hash 提交补丁时提出的

这篇文章简单介绍一下 Ruby 哈希表的基础和 2.4 改变

Ruby 是如何实现哈希表的

我们从用数组实现哈希表开始，起名叫 TurboHash:

class TurboHash
  attr_reader :table

  def initialize
    @table = []
  end
end

我们使用@table数组保存条目，然后添加方法去设置和读取条目：

class TurboHash
  def [](key)
    find(key).last
  end

  def find(key)
    # 遍历数组查找对应的条目
    @table.find do |entry|
      key == entry.first
    end
  end

  def []=(key, value)
    if entry = find(key)
      entry[1] = value
    else
      @table << [key, value]
    end
  end
end

写个 benchmark 来对比一下原生 Hash 的性能

require "benchmark"

legacy = Hash.new
turbo  = TurboHash.new

n = 10_000

def set_and_find(target)
  key = rand
  target[key] = rand
  target[key]
end

Benchmark.bm do |x|
  x.report("Hash: ") { n.times { set_and_find(legacy) } }
  x.report("TurboHash: ") { n.times { set_and_find(turbo) } }
end

很惨，在我的电脑上，比原生的慢了 1000 倍

       user     system      total        real
Hash:   0.010000   0.000000   0.010000 (  0.004094)
TurboHash:  10.070000   0.050000  10.120000 ( 10.240642)

瓶颈在于到后面查找条目的时候，每次都要遍历近万个条目，很明显，原生的 Hash 不是通过遍历数组这种方式来实现的。

在 Ruby 2.4 之前，Ruby 采用的是哈希值链表法

一个对象在被放置入哈希表之前，会调用它的 hash 方法得到一个整数，然后对整数取模，获取它所在节点，如果这个节点为空，则在这个节点创建一个链表，将这个对象放置入链表，反之则添加到这个链表。

我们用这个方法来改一下之前的 TurboHash

class Node
  attr_reader :object, :next

  def initialize(o, n)
    @object = o
    @next = n
  end
end

class TurboHash
  NUM_BINS = 11

  attr_reader :table

  def initialize
    @table = Array.new(NUM_BINS)
  end

  def [](key)
    if node = node_for(key)
      begin
        return node.object[1] if node.object[0] == key
      end while node = node.next
    end
  end

  def node_for(key)
    @table[index_of(key)]
  end

  def index_of(key)
    key.hash % NUM_BINS
  end

  def []=(key, value)
    @table[index_of(key)] = Node.new([key, value], node_for(key))
  end
end

再来运行一下 benchmark，不敢相信自己的眼睛，已经和原生 Hash 一样快了？？只是把原先一个大数组遍历，改成了分开用 11 个格子分开存储，然后用链表遍历，理论上性能应该只是变快了 11 倍左右：

       user     system      total        real
Hash:   0.010000   0.000000   0.010000 (  0.003859)
TurboHash:   0.010000   0.000000   0.010000 (  0.014998)

真相是我这里特别针对 benchmark 的代码作弊了，每次往链表添加对象的时候，都加到了链表的最前面，而 benchmark 代码每次都是读取最后添加对象的 key，不用遍历整个链表，自然会很快，如果把 benchmark 代码修改一下：

def set_and_find(target)
  keys = Array.new(30000) {rand}
  keys.each do |key|
    target[key] = rand
  end.shuffle.each do |key|
    target[key]
  end
end

和单数组遍历相比，性能确实只提高了一个数量级，从慢 1000 倍变成慢 100 倍，这也从一个侧面说明了单一或者简单的性能测试代码都是骗人的 ^_^

       user     system      total        real
Hash:   0.020000   0.000000   0.020000 (  0.019680)
TurboHash:   2.360000   0.010000   2.370000 (  2.375549)

现在瓶颈在放置入 Hash 中的对象变多以后，数组对应元素的链表会变长，每次读取的时候，都要遍历。如果随着对象增加进行扩容，可以解决这个瓶颈。

让我们抄袭一下 Ruby 的源代码，再来改进 TurboHash:

class TurboHash
  STARTING_BINS = 16

  attr_reader :table

  def initialize
    @max_density = 5
    @entry_count = 0
    @bin_count   = STARTING_BINS
    @table = Array.new(@bin_count)
  end

  def grow
    @bin_count = @bin_count << 1
    new_table = Array.new(@bin_count)
    @table.each do |node|
      if node
        begin
          new_index = index_of(node.object[0])
          new_table[new_index] = Node.new(node.object, new_table[new_index])
        end while node = node.next
      end
    end
    @table = new_table
  end

  def full?
    @entry_count > @max_density * @bin_count
  end

  def [](key)
    if node = node_for(key)
      begin
        return node.object[1] if node.object[0] == key
      end while node = node.next
    end
  end

  def node_for(key)
    @table[index_of(key)]
  end

  def index_of(key)
    key.hash % @bin_count
  end

  def []=(key, value)
    grow if full?
    @table[index_of(key)] = Node.new([key, value], node_for(key))
    @entry_count += 1
  end
end

通过一个 entry_count 计数器来统计 Hash 表里的元素个数，当超过一定数量的时候，通过 grow 方法进行扩容，这里初始的 16 个数组个数和平均 5 个密度，都是从 Ruby 源代码中抄过来的。我们再来看一下性能测试结果：

       user     system      total        real
Hash:   0.020000   0.000000   0.020000 (  0.021225)
TurboHash:   0.090000   0.000000   0.090000 (  0.088481)

已经差不多在一个数量级了，这也基本上就是 Ruby 2.4 之前的 Hash 实现方法，当然实际的原生 Hash 实现代码要比这个复杂很多，还要考虑删除元素，扩容机制的优化，以及一些小细节优化。

Ruby 2.4 之前的 2 个小细节优化

2.0 时候针对小于 7 个元素的 Hash 不额外创建链表结构，直接放置入数组，用数组遍历来实现，我们可以从性能测试代码中看到，达到 7 个元素的时候，性能有个阶梯式的差异：

require 'benchmark/ips'
Benchmark.ips do |x|
  3.upto(10) do |i|
    x.report(i) do
      h = {}
      i.times do |j|
        h[j.to_s] = j
      end
    end
  end
end

2.2时候，得益于Object#hash方法的改进，hash值更加均匀分布，从质数取模改成了用位操作：

def index_of(key)
  key.hash & @bin_count - 1
end

Ruby 2.4 Hash 的改变

Ruby 2.4 采用了Open addressing改进 Hash 的性能，和之前的实现方法差异主要在于：不再额外维护一个链表结构，每次都是按 hash 索引在数组插入，如果要插入的位置已经有元素存在，那么就找到一个空的位置插入。

这种做法称为线性探测，上图中用的就是最简单的 +1 依次探测，但是这种实现在元素较多的时候，每次插入和读取时，都很容易发生索引已经被占用的情况，然后要依次遍历，性能很差

Ruby 2.4 采用了随机探测 ( Random Probing ) 来解决这个问题，最简单随机探测实现方法就是加一个伪随机值来探测下一个空位，伪随机值的作用是保证读取的时候随机值和放置时候一样，不会有性能问题。

类似 Random，伪随机值就是给定一个起始的数值，每次产生的随机数顺序都是一样的：

irb> r = Random.new(7)
irb> r.rand(1..100)
# => 48
irb> r.rand(1..100)
# => 69
irb> r.rand(1..100)
# => 26

irb> r = Random.new(7)
irb> r.rand(1..100)
# => 48
irb> r.rand(1..100)
# => 69
irb> r.rand(1..100)
# => 26

Ruby 2.4 采用了线性同余方法来实现一个伪随机值队列：

Xn+1 = (a * Xn + c ) % m

只要满足如下 4 个条件，这个算法就可以产生伪随机值队列：

m > 0

0 < a < m

0 <= c < m

0 <= X0 < m

我们选取 a＝3, c=1, m=16 来试试看：

irb> a, x_n, c, m = [3, 1, 4, 16]

irb> x_n = (a * x_n + c) % m
 => 7
irb> x_n = (a * x_n + c) % m
 => 9
irb> x_n = (a * x_n + c) % m
 => 15
irb> x_n = (a * x_n + c) % m
 => 1

但是在上面的 a,c,m 初始值的选择下，这个队列在获取了 4 次随机值之后就开始循环了，达不到依次遍历所有位置（0 到 m）的需求。

只要通过选择不同的 a,c,m 初始值，满足一定条件，是可以实现了完整周期线性同余方法（Full Cycle Linear Congruential Generator）

m 和 c 互质

(a - 1) 能被 m 的所有质因数整除

如果 m 能被 4 整除，那么 (a - 1) 也必须能被 4 整除

源码中，是采用了这样的数据 a=5, c=1, m 为 2 的 N 次方（ https://github.com/ruby/ruby/blob/trunk/st.c#L801 ）

我们来试一下：

irb> a, x_n, c, m = [5, 7, 1, 16]

irb> x_n = (a * x_n + c) % m
# => 4
irb> x_n = (a * x_n + c) % m
# => 5
irb> x_n = (a * x_n + c) % m
# => 10

irb> (1..16).map { x_n = (a * x_n + c) % m }.sort
# => [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15]

正是通过 Open addressing 避免了额外的数据结构，所以 Ruby 2.4 Hash 的内存使用减少了：

然后通过完整周期线性同余方法，保证所有对象尽可能在内存中是相邻存放，CPU 在读取内存时，会预读取同一区块的相邻数据到 CPU 缓存，所以 Ruby 2.4 Hash 的性能也有了很大提高：

数据来源：https://rubybench.org/ruby/ruby/releases?result_type=hash_small8

最后，本文基本上是以下两篇文章的翻译和改编：

https://blog.heroku.com/ruby-2-4-features-hashes-integers-rounding#hash-changes

http://blog.redpanthers.co/behind-scenes-hash-table-performance-ruby-2-4/

最后的最后，如果你有几个小时来阅读 2.4 Hash 的这个补丁会发现有很多有趣的内容

Google App Engine 支持 Ruby 了

quakewang — Mon, 09 May 2016 10:15:56 +0800

We’re excited to announce that Ruby runtime on Google App Engine is going beta. Frameworks such as Ruby on Rails and Sinatra make it easy for developers to rapidly build web applications and APIs for the cloud. App Engine provides an easy to use platform for developers to build, deploy, manage, and automatically scale services on Google’s infrastructure.

https://cloudplatform.googleblog.com/2016/05/Ruby-on-Google-App-Engine-goes-betaruntime.html

自制监控服务接收 NewRelic RPM 数据

quakewang — Fri, 13 Nov 2015 17:19:06 +0800

据我了解社区里面很多人都在用 NewRelic，最近空闲时间在折腾自制监控服务来接收 NewRelic rpm 数据，写篇短文分享一下。

首先我们需要一个服务能够处理 rpm 发出的数据，通过 rpm 的源代码，测试案例和相关资料，可以一个个 api 地逆向工程出服务器端的代码： https://github.com/quake/rpm_selfhost/blob/master/rpm_selfhost.rb

目前粗糙地实现了 3 个接口：analytic_event_data / metric_data / error_data，通过 rackup 命令来启动这个服务。

然后我们需要这个服务能接收到 rpm 上报的数据，通过查看 rpm 的源代码，有 2 种可能的实现方式： 1.修改配置文件：config/newrelic.yml，让原本发给 NewRelic 服务器的数据，直接发给自己的服务

host: localhost
port: 9292
api_host: localhost
api_port: 9292
ssl: false

这个方法的好处是实现简单，方便在测试环境调试，缺点是 NewRelic 本身无法再收到应用的数据。

2.修改配置文件：config/newrelic.yml，记录上报数据的日志：

audit_log:
  enabled: true

通过日志处理脚本将日志导入： https://github.com/quake/rpm_selfhost/blob/master/log_import.rb 这个方法的好处是 NewRelic 也可以收到数据，缺点是非实时

这个服务存储用的 InfluxDB，按官方文档安装，然后创建一个名叫 collector 的数据库即可。

在数据接收完毕以后，我们可以通过 Grafana 这个工具来做展示，按官方文档安装以后，开始制作自己的 Dashboard，比如说 Throughput，我们写这样的查询：

SELECT count("duration") AS "duration" FROM "analytic_event_data" WHERE "type" = 'Transaction' and "name" !~ /^Controller\/Middleware\// AND $timeFilter GROUP BY time($interval)

然后设置相关的参数，比如说 Group by time interval >60s

再比如说请求的响应时间：

SELECT 1000 * mean("duration")  FROM "analytic_event_data" WHERE $timeFilter and type = 'Transaction' and "name" !~ /^Controller\/Middleware\// GROUP BY time($interval)

这样就可以看到还不错的图表了：

以上这 2 个图表可以导入 Grafana 的 Dashboard json 文件直接看到： https://github.com/quake/rpm_selfhost/blob/master/grafana.json

目前这个项目只实现了几个最简陋的图表，还只是一个玩具，欢迎有兴趣的同学们来 fork 这个项目（ https://github.com/quake/rpm_selfhost ），有几个点可以玩： (已完成)1. 实现更多的 api，比如说 connect 这个 api，需要记录上报数据的 host 信息，返回给 rpm agent 一个 agent_run_id(目前是写死 123)，建立 host 和 agent_run_id mapping 关系，这样才能实现多台主机的情况下按主机来分开统计。

查看 rpm 客户端源码，理解上报数据的逻辑关系，通过 Grafana 展现更多的图表
实现代理模式，将上报 NewRelic 的数据在本地同时保存一份
将项目 gem 化，数据库信息、端口信息配置化，通过一个命令即可启动服务

参考资料 https://mic-kul.com/2015/10/24/garage-made-self-hosted-newrelic-collector-using-ruby-sinatra-grafana-and-influxdb/ https://ruby-china.org/topics/23470

=================12 月 1 号更新的分割线================================== 完成了 connect api，能够支持多台主机和多个应用，进行过滤展示：

[上海] 蝉游记 / 携程周末招聘 Ruby 工程师

quakewang — Mon, 01 Jun 2015 16:06:03 +0800

团队介绍

「蝉游记」( http://chanyouji.com ) 创立于 2012 年，13 年被携程投资，14 年底被携程全资收购。并入携程后，成立了一个新的微型事业部，由做蝉游记和玩票产品的蝉小队，以及做「携程周末」（https://itunes.apple.com/cn/app/id986276381?mt=8）这款新产品的城市猎人小队构成。

携程周末是今年启动的新项目，5 月初发布，定位于“城市玩乐指南”。这也是接下来主打的产品。目前开通了北上广杭四个城市，接下来会开通深圳和成都。

「蝉游记」发布两年半，定位于“旅行资讯与工具”，2014 年至今在苹果线下门店被选为 iPhone 样机内置应用，算是蝉小队的代表作。5 月初发布的蝉游记 5.0(iOS 版) 合并了另一款 App 蝉游攻略，提供更强大的旅行攻略。

除了主力产品，蝉小队还有一些玩票 App，包括已经发布的形态奇特的「生辰」，和列入下半年研发计划，伺机而动的另外几款玩票产品。

工作职责

为上述 App 提供管理后台以及 API 的设计、开发、维护

基本要求

一年以上 RoR 开发经验熟悉关系型数据库熟悉常见的业务建模方法

加分项

熟悉前端技术熟悉 Linux 系统的部署和维护有业务代码重构经验

工作地点

上海福泉路 99 号，靠近地铁 2 号线淞虹路站，交通便利

福利待遇

月薪范围在 10k~20k，每年 14+ 月，具体面谈简历请发送：quake@chanyouji.com 来信请附上你的 ruby-china 帐号/github 帐号/个人博客地址/Twitter or 微博地址（以上都没有的话......

Ruby 中的函数式编程

quakewang — Thu, 30 Apr 2015 17:55:23 +0800

为培训由其他编程语言转到 Ruby 的程序员，写了一些 PPT，其中涉及到了一些函数式编程，反馈还不错，于是抽取出来写了一篇短文。

什么是函数式编程

跳过...请自己 Google

函数式编程有什么好处

会让你的代码看起来更屌（实际并不... 会让你的工资增加（做梦... 会让你写的程序性能更好（一般来说没差别...

到底有什么好处...请自己 Google

请先做道题

奇偶归一猜想（英语：Collatz conjecture），是指对于每一个正整数，如果它是奇数，则对它乘 3 再加 1，如果它是偶数，则对它除以 2，如此循环，最终都能够得到 1。如 n = 6，根据上述数式，得出序列 6, 3, 10, 5, 16, 8, 4, 2, 1。(步骤中最高的数是 16，共有 8 个步骤) 如 n = 8，根据上述数式，得出序列 8, 4, 2, 1。(步骤中最高的数是 8，共有 3 个步骤) 如 n = 11，根据上述数式，得出序列 11, 34, 17, 52, 26, 13, 40, 20, 10, 5, 16, 8, 4, 2, 1。(步骤中最高的数是 52，共有 14 个步骤)

给定一个数组，对这个数组里面的每个数字做奇偶归一操作，找出步骤最多的一个序列，比如输入 [4, 6, 8, 11] 返回 [11, 34, 17, 52, 26, 13, 40, 20, 10, 5, 16, 8, 4, 2, 1]

Ruby 中的函数式编程

不更新变量

array 的 << vs +

def f(array)
  array << 42
end

def f(array)
  array + [42]
end

hash 的 []= vs merge

def f(hash)
  hash[:foo] = 42
  hash
end

def f(hash)
  hash.merge(foo: 42)
end

不依赖外部变量

一个例子，常见其他语言转过来的程序员写的 ruby 代码，将一个数组中的字符串转换成大写输出：

countries = []
["china", "usa"].each do |name|
  countries << name.upcase
end
countries # => ["CHINA", "USA"]

依赖了外部变量（countries），同时还对变量做了更新（<<）

函数式编程，使用 map：

countries = ["china", "usa"].map do |name|
  name.upcase
end # => ["CHINA", "USA"]

再一个例子，加总数组中字符串长度：

length = 0
["china", "usa"].each do |name|
  length += name.length
end
length # => 8

函数式编程，使用 inject：

length = ["china", "usa"].inject(0) do |memo, name|
  memo + name.length
end # => 8

还可以使用语法糖，简写方式：

length = ["china", "usa"].map(&:length).inject(0, :+)

了解 Enumerable/Array/Hash 的各种方法：map/inject/select/reject/scan/each/each_pair/each_cons...会让你写出不一样的代码。

Currying

另外一个比较好玩的特性，举个例子，我们可以假装发明了操作符前置的中文编程：

计算 = -> method, a, b { a.send method, b }
加 = 计算.curry[:+]
减 = 计算.curry[:-]
乘 = 计算.curry[:*]
除 = 计算.curry[:/]
加[2, 乘[4, 10]] # => 42

加1 = 加.curry[1]
加1[41]         # => 42

在 Ruby 里面 proc 调用可以用 proc.call, proc.(), 或者 proc[], 我比较喜欢 proc[] 这种方式。

回到最初的题目

首先写一个函数，来做奇偶判断对应的操作：

f0 = -> x {x.even? ? x / 2 : x * 3 + 1}

再写个函数，来判断是否到 1，返回序列：

f1 = -> x {x == 1 ? [x] : [x] + f1[f0[x]]}

最后写个函数，将输入的数组做 map，然后取序列最大的：

f2 = -> x {x.map{|e| f1[e]}.max_by{|e| e.size}}

输出：

f2[(10..20).to_a]
 => [18, 9, 28, 14, 7, 22, 11, 34, 17, 52, 26, 13, 40, 20, 10, 5, 16, 8, 4, 2, 1]

你最初写的代码会是怎样？对比一下，是否函数式编程真的体现了”describe what to do, rather than how to do it“

程序员的好玩具 - Lego EV3

quakewang — Fri, 13 Feb 2015 11:45:50 +0800

本来准备这周二上海 Tuesday 上将 EV3 带过去的，想秀一下用 ruby 代码来控制 EV3 机器人，可惜时间冲突没去成，发个评测补一下：

http://knewone.com/things/lego-ev3/reviews/54dd72dd31302d357f5d0000

年后有空再来秀。

Redis 作为缓存服务器的配置

quakewang — Wed, 19 Nov 2014 15:49:16 +0800

随着 redis 的发展，越来越多的架构用它取代了 memcached 作为缓存服务器的角色，它有几个很突出的特点：

除了 Hash，还提供了 Sorted Set, List 等数据结构
可以持久化到磁盘
支持 cluster (3.0)

它的性能和 memcached 不相上下，再加上流行的其他组件（比如队列）也会用到 redis，从架构简单出发，已经没有必要混用 redis 和 memcached 了。

写篇短文介绍一下用 redis 作为缓存服务器配置时候需要注意几个点。

Redis 配置

作为缓存服务器，如果不加以限制内存的话，就很有可能出现将整台服务器内存都耗光的情况，可以在 redis 的配置文件里面设置：

# 限定最多使用1.5GB内存
maxmemory 1536mb

如果内存到达了指定的上限，还要往 redis 里面添加更多的缓存内容，需要设置清理内容的策略：

# 设置策略为清理最少使用的key对应的数据
maxmemory-policy allkeys-lru

清理策略有多种，redis 的官方文档有一篇很详细的说明： http://redis.io/topics/lru-cache

Redis 监控

redis 提供了 INFO 这个命令，能够随时监控服务器的状态，只用 telnet 到对应服务器的端口，执行命令即可：

telnet localhost 6379
info

在输出的信息里面有这几项和缓存的状态比较有关系：

keyspace_hits:14414110
keyspace_misses:3228654
used_memory:433264648
expired_keys:1333536
evicted_keys:1547380

通过计算 hits 和 miss，我们可以得到缓存的命中率：14414110 / (14414110 + 3228654) = 81% ，一个缓存失效机制，和过期时间设计良好的系统，命中率可以做到 95% 以上，对于整体性能提升是很大的。 used_memory,expired_keys,evicted_keys 这 3 个信息的具体含义，redis 的官方也有一篇很详细的说明： http://redis.io/commands/info

有个 ruby gem 叫 redis-stat，它利用 INFO 命令展现出更直观的信息报表，推荐： https://github.com/junegunn/redis-stat

优化 Rails 的缓存配置

Rails 在用 redis 作为缓存的时候，配置很简单，官方文档是用 schema 的方式来写的：

config.cache_store = :redis_store, "redis://localhost:6379/0/cache"

由于实在太简单了，很多人就直接用这个默认设置了，但实际上还有一些很有用的参数可以通过 hash options 的方式来写，比如压缩超过 32K 的数据压缩以后再放入缓存，再比如设置默认所有的 key 失效时间为 8 小时：

config.cache_store = :redis_store, {:host => 'redis.server', :port => 6379, :compress => true, :expires_in => 8.hours, :compress_threshold => 32.kilobytes}

用一个实际案例来作为例子，一台 redis 缓存服务器在优化配置之前，占用 4.2G 左右的内存，缓存命中率在 70% 左右。我们先在服务器上执行 BGSAVE 命令，将内存 dump 下来，然后用 https://github.com/sripathikrishnan/redis-rdb-tools 这个工具，将 dump 的数据，解析成 csv 文件：

rdb -c memory /var/redis/6379/dump.rdb > memory.csv

用 excel 打开分析，按 key 进行排序和统计，我们可以看到哪一些类型的缓存在服务器上最多，调整这个类型缓存的失效时间和失效机制，再通过 redis-stat 来观察进行微调，提高整体的命中率。通过分析占用内存比较大的 key，发现有 30% 左右的相同类型 key，用了 95% 的内存，这些缓存大部分是 html 的片段缓存，通过设置 compress_threshold 和 compress 参数，让整体内存占用从 4.2G，下降到了 1.3G。

性能监控的好工具 - NewRelic 简介

quakewang — Fri, 31 Oct 2014 15:38:55 +0800

我们蝉游记服务器端性能监控一直用 http://newrelic.com/ ，用它的免费版本 N 长时间，有必要为好工具义务宣传一下。

首先你需要在网站上注册一个新帐号，根据服务器端的应用框架选择安装对应的插件，它提供了很多常见应用框架插件，以 Rails 为例子，只需要在 Gemfile 配置，执行 bundle install 即可：

gem 'newrelic_rpm'

然后下载对应的 newrlic.yml 配置文件，放入到应用目录，进行一些参数的调整。将应用重新部署以后，等几分钟，让插件收集到性能相关数据，再去访问 NewRelic 网站，就可以看到各种图表了。

首先需要关注的是请求的响应时间图表，用这个图表可以对请求在服务器端耗时有个整体印象：从图表上可以看到，在这个时间段，请求的平均耗时是 52ms，同时可以看到每个请求的 Ruby 代码和数据库执行时间占据了绝大部分，还有少量的外部服务调用时间（比如第 3 方 Oauth 或者 API)。由于我们使用 OOB GC，所以在图表上几乎没有 GC 的时间。

另外右上角有一个 3.58s 的浏览器时间，这个是指用户访问网页，从请求发出，到整个页面完全加载完成（包括图片，css，js 等）。

第二个图表是 Apdex (Application Performance Index)，从这里可以看到大部分用户是否满意你的应用响应速度：

从图表可以看到，99% 的用户非常满意请求响应时间（在我们的应用里面，大部分请求是客户端调用 api），93% 的用户非常满意页面加载完成的时间。我们用的指标是 NewRelic 默认设置的 500ms 和 7s，你还可以自己进行调整。

第 3 个图表是吞吐量可以看出在这半个小时的区间，平均每分钟有 1050 个请求。用这个图表，通过調整时间段（，了解整个应用什么时候是高峰，什么时候是低谷，方便将一些批处理，备份等任务放在访问低谷的时间段进行。还有当用户报告无法访问的时候，可以通过查看吞吐量是否有急剧下降，来判断是个例还是整体故障，来确定解决问题的优先级。免费版本的 NewRelic，只能查看过去 24 小时的数据，升级到付费帐号，可以查看所有的历史数据。

第 4 个图表是根据请求的时间和请求的次数，列出一个最耗时的请求我们可以根据这个排列顺序，来考虑对于访问量大，同时又耗时的请求进行重点性能优化。点击具体的请求，还可以看到请求耗时的分布情况：从图表上可以看到这个请求，在渲染 json 数据耗费了比较多的时间，另外在 ActiveRecord 的查询上也耗费了一些时间，如果要优化的话，就可以从渲染结果加片段缓存，或者查询优化入手。升级到付费版本，还能查看到具体的 sql 语句执行情况，如果有 slow query，还能显示 explain 的结果。

第 5 个图表，是错误率在我们应用中引发错误的大部分是一些爬虫 404，还有一些是异常数据没有处理好导致，这里就不详细介绍了。这个图表对于用户反馈错误定位也是很有帮助的。

第 6 个图表，是应用性能分布到各个服务器状态对于了解服务器资源和扩容计划很有帮助。顺便说一个实际遇到的事情，发现过某台主机（我们用的云主机）的响应时间就是比其他台要慢 50% 以上，对比发现这台的 CPU 和 Disk IO 都比其他台要弱，后来报告给云主机服务商，通过迁移到了新的物理机解决了。

除了上述的这些性能图表，NewRelic 也提供了很多监控的选项，比如 ping，内存/存储警报等，可以将报警发送到邮件，或者推送到移动客户端：

这里就简单介绍一下它免费版本的少量功能，更多的功能留待大家去玩吧。最后还要提一下最喜欢的 scalability report 和 database report，可以申请试用付费帐号来体验，是我见过最赞的报表了。

Ruby 程序员写 Swift 毫无压力

quakewang — Tue, 03 Jun 2014 10:07:40 +0800

花半个小时看了一下 Swift 的文档，很开心地发现不需要学习它的语法，各位熟悉 ruby 语法的程序员就算不看文档，阅读 swift 代码也应该毫无压力，如果你之前熟悉 apple framework 的各种 api，那就赶紧转移到 swift 开发 ios 应用吧，因为终于可以抛弃 Objective C 这个上世纪的语言了 :)

swift 和 ruby 几个简单的对比：

swift 用 let 定义常量，用 var 定义变量 swift

let maximumNumberOfLoginAttempts = 10
var currentLoginAttempt = 0

ruby 无关键字，用大写字母代表常量 ruby

MAXIMUM_NUMBER_OF_LOGIN_ATTEMPTS = 10
currentLoginAttempt = 0

定义多个变量 swift

var x = 0.0, y = 0.0, z = 0.0

ruby

x, y, z = 0.0, 0.0, 0.0

字符串 swift

println("The current value of friendlyWelcome is \(friendlyWelcome)")

ruby

p "The current value of friendlyWelcome is #{friendlyWelcome}"

N 进制数字和各种数字格式，完全和 ruby 是一模一样... swift

let decimalInteger = 17
let binaryInteger = 0b10001 // 17 in binary notation
let octalInteger = 0o21 // 17 in octal notation
let hexadecimalInteger = 0x11 // 17 in hexadecimal notation


let decimalDouble = 12.1875
let exponentDouble = 1.21875e1
let hexadecimalDouble = 0xC.3p0

let paddedDouble = 000123.456
let oneMillion = 1_000_000
let justOverOneMillion = 1_000_000.000_000_1

Tuples, swift 需要定义类型组合，常用在多参数返回，而 ruby 则直接支持数组 swift

let http404Error = (404, "Not Found")
let (statusCode, statusMessage) = http404Error
let (justTheStatusCode, _) = http404Error

ruby

http404Error = [404, "Not Found"]
statusCode, statusMessage = http404Error
justTheStatusCode , _ = http404Error

条件绑定，这个很方便的语法糖，已经成为现代语言的标配： swift

if let actualNumber = possibleNumber.toInt() {
  println("\(possibleNumber) has an integer value of \(actualNumber)")
} else {
  println("\(possibleNumber) could not be converted to an integer")
}

ruby

if actualNumber = possibleNumber.toInt
  p "#{possibleNumber} has an integer value of #{actualNumber}"
else
  p "#{possibleNumber} could not be converted to an integer" 
end

遍历数组 swift

for item in shoppingList {
  println(item)
}

for (index, value) in enumerate(shoppingList) {
  println("Item \(index + 1): \(value)")
}

ruby

for item in shoppingList
  p item
end

#ruby的数组是Enumerable，遍历更常用each/each_with_index等方法
shoppingList.each_with_index{|value, index| p "Item #{index + 1}: #{value}"}

Dictionary swift

var airports = ["TYO": "Tokyo", "DUB": "Dublin"]
airports["LHR"] = "London"

for (airportCode, airportName) in airports {
  println("\(airportCode): \(airportName)")
}

ruby

airports = {TYO: "Tokyo", DUB: "Dublin"}
airports[:LHR] = "London"
airports.each{|airportCode, airportName| p "#{airportCode}: #{airportName}" }

Range swift

for index in 1...5 {
  println("\(index) times 5 is \(index * 5)")
}

Ruby 用..表示闭合区间，...表示开合区间 ruby

(1..5).each{|index| p "#{index} times 5 is #{index * 5}"}

Closures swift

let digitNames = [
  0: "Zero", 1: "One", 2: "Two", 3: "Three", 4: "Four",
  5: "Five", 6: "Six", 7: "Seven", 8: "Eight", 9: "Nine"
]
let numbers = [16, 58, 510]

let strings = numbers.map {
  (var number) -> String in
  var output = ""
  while number > 0 {
    output = digitNames[number % 10]! + output
    number /= 10
  }
  return output
}
// strings is inferred to be of type String[]
// its value is ["OneSix", "FiveEight", "FiveOneZero"]

ruby

digitNames = {
  0 => "Zero", 1 => "One", 2 => "Two", 3 => "Three", 4 => "Four", 
  5 => "Five", 6 => "Six", 7 => "Seven", 8 => "Eight", 9 => "Nine"
}
numbers = [16, 58, 510]
numbers.map do |number|
  output = ""
  while number > 0 
    output = digitNames[number % 10] + output
    number /= 10
  end
  output
end

总结 Web 应用中常用的各种 Cache

quakewang — Mon, 19 May 2014 18:02:36 +0800

总结 web 应用中常用的各种 cache

cache 是提高应用性能重要的一个环节，写篇文章总结一下用过的各种对于动态内容的 cache。文章以 Nginx，Rails，Mysql，Redis 作为例子，换成其他 web 服务器，语言，数据库，缓存服务都是类似的。以下是 3 层的示意图，方便后续引用：


                          +-------+
1                         | Nginx |
                          +-+-+-+-+
                            | | |
            +---------------+ | +---------------+
            |                 |                 |
        +---+---+         +---+---+         +---+---+
2       |Unicorn|         |Unicorn|         |Unicorn|
        +---+---+         +---+---+         +---+---+
            |                 |                 |
            |                 |                 |
            |             +---+---+             |
3           +-------------+  D B  +-------------+
                          +-------+

1. 客户端缓存

一个客户端经常会访问同一个资源，比如用浏览器访问网站首页或查看同一篇文章，或用 app 访问同一个 api，如果该资源和他之前访问过的没有任何改变，就可以利用 http 规范中的 304 Not Modified 响应头 ( http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.5 )，直接用客户端的缓存，而无需在服务器端再生成一次内容。在 Rails 里面内置了 fresh_when 这个方法，一行代码就可以完成：

class ArticlesController
  def show
    @article = Article.find(params[:id])
    fresh_when :last_modified => @article.updated_at.utc, :etag => @article
  end
end

下次用户再访问的时候，会对比 request header 里面的 If-Modified-Since 和 If-None-Match，如果相符合，就直接返回 304，而不再生成 response body。

但是这样会遇到一个问题，假设我们的网站导航有用户信息，一个用户在未登陆专题访问了一下，然后登陆以后再访问，会发现页面上显示的还是未登陆状态。或者在 app 访问一篇文章，做了一下收藏，下次再进入这篇文章，还是显示未收藏状态。解决这个问题的方法很简单，将用户相关的变量也加入到 etag 的计算里面：

fresh_when :etag => [@article.cache_key, current_user.id]
fresh_when :etag => [@article.cache_key, current_user_favorited]

另外提一个坑，如果 nginx 开启了 gzip，对 rails 执行的结果进行压缩，会将 rails 输出的 etag header 干掉，nginx 的开发人员说根据 rfc 规范，对 proxy_pass 方式处理必须这样（因为内容改变了），但是我个人认为没这个必要，于是用了粗暴的方法，直接将 src/http/modules/ngx_http_gzip_filter_module.c 这个文件里面的这行代码注释掉，然后重新编译 nginx：

//ngx_http_clear_etag(r);

或者你可以选择不改变 nginx 源代码，将 gzip off 掉，将压缩用 Rack 中间件来处理：

config.middleware.use Rack::Deflater

除了在 controller 里面指定 fresh_when 以外，rails 框架默认使用 Rack::ETag middleware，它会自动给无 etag 的 response 加上 etag，但是和 fresh_when 相比，自动 etag 能够节省的只是客户端时间，服务器端还是一样会执行所有的代码，用 curl 来对比一下。 Rack::ETag 自动加入 etag：

curl -v http://localhost:3000/articles/1
< Etag: "bf328447bcb2b8706193a50962035619"
< X-Runtime: 0.286958
curl -v http://localhost:3000/articles/1 --header 'If-None-Match: "bf328447bcb2b8706193a50962035619"'
< X-Runtime: 0.293798

用 fresh_when：

curl -v http://localhost:3000/articles/1 --header 'If-None-Match: "bf328447bcb2b8706193a50962035619"'
< X-Runtime: 0.033884

2. Nginx 缓存

有一些资源可能会被调用很多，又无关用户状态，并且很少改变，比如新闻 app 上的列表 api，购物网站上 ajax 请求分类菜单，可以考虑用 Nginx 来做缓存。主要有 2 种实现方法： A. 动态请求静态文件化在 rails 请求完成以后，将结果保存成静态文件，后续请求就会直接由 nginx 提供静态文件内容，用 after_filter 来实现一下：

class CategoriesController < ActionController::Base
  after_filter :generate_static_file, :only => [:index]

  def index
    @categories = Category.all
  end

  def generate_static_file
    File.open(Rails.root.join('public', 'categories'), 'w') do |f|
      f.write response.body
    end
  end
end

另外我们需要在任何分类更新的时候，删除掉这个文件，避免缓存不刷新的问题：

class Category < ActiveRecord::Base
  after_save :delete_static_file
  after_destroy :delete_static_file

  def delete_static_file
    File.delete Rails.root.join('public', 'categories')
  end
end

Rails 4 之前，处理这种生成静态文件缓存可以用内置的 caches_page，rails 4 之后变成了一个独立 gem actionpack-page_caching，和手工代码对比一下，

class CategoriesController < ActionController::Base
  caches_page :index

  def update
    #...
    expire_page action: 'index'
  end
end

如果只有一台服务器，这个方法简单又实用，但是如果有多台服务器，就会出现更新分类只能刷新自己本身这台服务器缓存的问题，可以用 nfs 来共享静态资源目录解决，或者用第 2 种：

B. 静态化到集中缓存服务首先我们得让 Nginx 有直接访问缓存的能力：

upstream redis {
  server redis_server_ip:6379;
}

upstream ruby_backend {
  server unicorn_server_ip1 fail_timeout=0;
  server unicorn_server_ip2 fail_timeout=0;
}

location /categories {
  set $redis_key $uri;
  default_type   text/html;
  redis_pass redis;
  error_page 404 = @httpapp;
}

location @httpapp {
  proxy_pass http://ruby_backend;
}

Nginx 首先会用请求的 uri 作为 key 去 redis 里面获取，如果获取不到（404）就转发给 unicorn 进行处理，然后改写 generate_static_file 和 delete_static_file 方法：

redis_cache.set('categories', response.body)
redis_cache.del('categories')

这样除了集中管理以外，还能够设置缓存的失效时间，对于一些更新无时效性要求的数据，就可以不用处理刷新机制，简单地固定时间刷新一次：

redis_cache.setex('categories', 3.hours.to_i, response.body)

3. 整页缓存

Nginx 缓存在处理带参数资源或者有用户状态的请求时候，就非常难以处理，这个时候可以用到整页缓存。比如说分页请求列表，我们可以将 page 参数加入到 cache_path：

class CategoriesController
  caches_action :index, :expires_in => 1.day, :cache_path => proc {"categories/index/#{params[:page].to_i}"}
end

比如说我们只需要针对 rss 输出进行缓存 8 小时：

class ArticlesController
  caches_action :index, :expires_in => 8.hours, :if => proc {request.format.rss?}
end

再比如说对于非登陆用户，我们可以缓存首页：

class HomeController
  caches_action :index, :expires_in => 3.hours, :if => proc {!user_signed_in?}
end

4. 片段缓存

如果说前面 2 种缓存能够用到的场景有限，那么片段缓存是适用性最广的。

场景 1：我们需要在每个页面一段广告代码，用来显示不同广告，如果没有使用片段缓存，那么每个页面都会要去查询广告的代码，并且花费一定时间去生成 html 代码：

- if advert = Advert.where(:name => request.controller_name + request.action_name, :enable => true).first
  div.ad
    = advert.content

加了片段缓存以后，就可以少去这个查询：

- cache "adverts/#{request.controller_name}/#{request.action_name}", :expires_in => 1.day do
  - if advert = Advert.where(:name => request.controller_name + request.action_name, :enable => true).first
    div.ad
      = advert.content

场景 2：阅读文章，文章的内容可能比较长时间都不会改变，经常变化可能是文章评论，就可以对文章主体部分加上片段缓存：

- cache "articles/#{@article.id}/#{@article.updated_at.to_i}" do
  div.article
    = @article.content.markdown2html

节约了生成 markdown 语法转换到 html 时间，这里用文章最后更新时间作为 cache key 的一部分，文章内容如果有改变，缓存自动失效，默认 activerecord 的 cache_key 方法也是用 updated_at，你也可以加入更多的参数，比如 article 上有评论数的 counter cache，更新评论数的时候不会更新文章时间，可以将这个 counter 也加入到 key 的一部分

场景 3：复杂页面结构的生成数据结构比较复杂的页面，在生成的时候避免不了大量的查询和 html 渲染，用片段缓存，可以将这部分时间大大地节约，以我们网站游记页面 http://chanyouji.com/trips/109123 （请允许小小地打个广告，带点流量）来说：需要获取天气数据，照片数据，文本数据等，同时还要生成 meta，keyword 等 seo 数据，而这些内容又是和其他动态内容交叉，片段缓存就可以分开多个：

- cache "trips/show/seo/#{@trip.fragment_cache_key}", :expires_in => 1.day do
  title #{trip_name @trip}
  meta name="description" content="..."
  meta name="keywords" content="..."

body
  div
    ...
- cache "trips/show/viewer/#{@trip.fragment_cache_key}", :expires_in => 1.day do
  - @trip.eager_load_all

小贴士，我在 trip 对象里面加了一个 eager_load_all 方法，缓存没有命中的时候，查询的时候避免出现 n+1 问题：

def eager_load_all
  ActiveRecord::Associations::Preloader.new([self], {:trip_days => [:weather_station_data, :nodes => [:entry, :notes => [:photo, :video, :audio]]]}).run
end

小技巧 1：带条件的片段缓存和 caches_action 不同，rails 自带的片段缓存是不支持条件的，比如说我们想未登陆用户给他用片段缓存，而登陆用户不使用，写起来就很麻烦，我们可以改写一下 helper 就可以了：

  def cache_if (condition, name = {}, cache_options = {}, &block)
    if condition
      cache(name, cache_options, &block)
    else
      yield
    end
  end

- cache_if !user_signed_in?, "xxx", :expires_in => 1.day do

小技巧 2：关联对象的自动更新常使用对象 update_at 时间戳来作为 cache key，可以在关联对象上加上 touch 选项，自动更新关联对象时间戳，比如我们可以在更新或者删除文章评论的时候，自动个更新：

class Article
  has_many :comments
end

class Comment
  belongs_to :article, :touch => true
end

5. 数据查询缓存

通常来说 web 应用性能瓶颈都出现在 DB IO 上，做好数据查询缓存，减少数据库的查询次数，可以极大提高整体响应时间。数据查询缓存分 2 种： A. 同一个请求周期内的缓存举一个显示文章列表的例子，输出文章标题和文章类别，对应代码如下

# controller
  def index
    @articles = Article.first(10)
  end

# view
- @articles.each do |article|
  h1 = article.name
  span = article.category.name

会发生 10 条类似的 sql 查询：

SELECT `categories`.* FROM `categories` WHERE `categories`.`id` = ?

rails 内置了 query cache（ https://github.com/rails/rails/blob/master/activerecord/lib/active_record/connection_adapters/abstract/query_cache.rb ），在同一个请求周期内，如果没有 update/delete/insert 的操作，会对相同的 sql 查询进行缓存，如果文章类别都是相同的话，真正去查询数据库只会有 1 次。

如果文章类别都不一样，就会出现 N+1 查询问题（常见的性能瓶颈），rails 推荐的解决方法是用 Eager Loading Associations ( http://guides.rubyonrails.org/active_record_querying.html#eager-loading-associations )

def index
  @articles = Article.includes(:category).first(10)
end

查询语句会变成

SELECT `categories`.* FROM `categories` WHERE `categories`.`id` in (?,?,?...)

B. 跨请求周期的缓存同请求周期缓存所带来性能优化是很有限的，很多时候我们需要用跨请求周期的缓存，将一些常用的数据（比如 User model）缓存，对于 active record 来说，利用统一的查询接口来 fetch cache，利用 callback 来 expire cache，就很容易实现，而且有一些现成的 gem 可以来用。

比如说 identity_cache ( https://github.com/Shopify/identity_cache )

class User < ActiveRecord::Base
  include IdentityCache
end

class Article < ActiveRecord::Base
  include IdentityCache
  cached_belongs_to :user
end

# 都会命中缓存
User.fetch(1)
Article.find(2).user

这个 gem 的优点是代码实现简单，cache 设置灵活，也方便扩展，缺点是需要用不同的查询方法名（fetch），以及额外的关系定义。

如果想在无数据缓存的应用无缝加入缓存功能，推荐@hooopo 做的 second_level_cache ( https://github.com/hooopo/second_level_cache ) 。

class User < ActiveRecord::Base
  acts_as_cached(:version => 1, :expires_in => 1.week)
end

#还是使用find方法，就会命中缓存
User.find(1)
#无需额外用不一样的belongs_to定义
Article.find(2).user

实现原理是扩展了 active record 底层 arel sql ast 处理（ https://github.com/hooopo/second_level_cache/blob/master/lib/second_level_cache/arel/wheres.rb ）它的优点是无缝接入，缺点是扩展比较困难，对于只获取少量字段的查询无法缓存。

6. 数据库缓存

编辑中

这 6 种缓存，分布在客户端到服务器端不同的位置，所能够节约的时间也正好从多到少依次排列。

升级 Ruby 2.1 以及 GC 调整

quakewang — Fri, 28 Feb 2014 16:55:03 +0800

Ruby 从 1.8 => 1.9 => 2.0 => 2.1 一直在 GC 上不断地改进，最近 2.1.1 刚刚发布，抽空将我们的应用从 2.0 升级了一下，记录一下相关改动。

我们在服务器使用的是 rvm，首先更新一下 rvm：

rvm get head

淘宝提供了 ruby 相关的镜像，可以更新一下源，后续安装会快很多：

sed -i 's!cache.ruby-lang.org/pub/ruby!ruby.taobao.org/mirrors/ruby!' $rvm_path/config/db

安装 2.1.1：

rvm install 2.1.1

建议使用 railsexpress 的性能优化补丁（其中包括已经合并到 ruby 2.2 method cache 的改进）：

rvm install 2.1.1 --patch railsexpress

设置 2.1.1 为默认版本：

rvm use 2.1.1 --default

OobGC 优化：我们之前使用的 unicorn 自带的 OobGC，它会固定在每 N 次请求后，执行一次 GC。tmm1 写了另一个 OobGC: https://github.com/tmm1/gctools ，它利用 ruby 2.1 新的 gc 事件，使用 c 扩展来进行更智能的 OobGC，配置很简单，在 config.ru 里面加上：

require 'gctools/oobgc'
use GC::OOB::UnicornMiddleware

不过他不支持请求阶段的 GC.disable，实际用我们的应用测下来和 unicorn 自带的 OobGC+GC.disable 相比，在普通压力测试下，平均响应时间稍慢 2~3%，服务器的 cpu 消耗会少 2% 左右。

除了 OobGC 外，这个 gem 还提供了 GC 的日志输出，只要加上：

require 'gctools/logger'

可以在 stderr 看到具体的 GC 执行情况，用来判断 GC 参数调整是否合理十分有用。

GC 参数调整：和 Ruby 2.0 相比，2.1 多了一些分代 GC 的参数，这篇文章 http://tmm1.net/ruby21-rgengc/ 非常详细地介绍了各个参数的意义，还提供了 github 用的参数配置。配合 gctools/logger，我们最终调整的 GC 参数如下：

export RUBY_GC_HEAP_INIT_SLOTS=500000
export RUBY_GC_HEAP_FREE_SLOTS=700000
export RUBY_GC_HEAP_GROWTH_FACTOR=1.25
export RUBY_GC_HEAP_GROWTH_MAX_SLOTS=300000
export RUBY_GC_MALLOC_LIMIT=80000000
export RUBY_GC_OLDMALLOC_LIMIT=80000000

周末活动介绍 Prawn 的 Slide

quakewang — Mon, 25 Nov 2013 18:24:09 +0800

http://quake.github.io/slides/prawn/index.html

简单介绍了一下 Prawn，顺带打了一下广告，主要目的是去参观薄荷网的小别墅，环境确实很赞！

[免费] 转让 RubyConfChina 门票一张

quakewang — Thu, 17 Oct 2013 11:49:37 +0800

很杯具地...下周末公司搬家要去做苦力，帝都我来不了了...

如果你是学生，请附上 github 账号，免费转让，随机抽一个。

有意向的同学，请回复吧，本周末前截至。

====抽奖分割线==== irb(main):004:0> %w(cassiuschen wcp1231 KuangyinWang shatle undoZen qinfanpeng shawzt GeassX).sample => "KuangyinWang"

[上海] 蝉游记 - 一大波职位正在向你靠近

quakewang — Wed, 25 Sep 2013 15:11:38 +0800

写在前面的话

以下招聘内容是我的合伙人写的，原文在： http://firecacada.blog.163.com/blog/static/707437620138252491850/ 虽然我们这次的一大波职位里面没有 Ruby 工程师，但是我还是想转发在 Ruby 社区试试看，如果碰巧看贴的你既熟悉 Ruby，又有丰富的 Android 开发经验也说不定，这可是豪大大的加分项。或者又碰巧你的好友有符合其他岗位的要求，不妨转给他看看。

以下是正文

hi，我是蝉游记 lv2。你们可能认识我的小伙伴蝉游记 lv1，一款以华丽画卷为卖点的游记制作工具，有网站版与iPhone、iPad版本，在今年极客公园举办的创新产品大赛中，拿过“最佳体验奖”，App 多次进入 AppStore 首页编辑选荐。

现在，lv1 升级到了 lv2，蝉小队招聘启动，一大波职位正在向你靠近。

提前点名：Android 工程师，Android 产品经理，目的地运营，市场营销，UI 设计师，行政

关于蝉游记 lv2

虽然 lv1 以游记为主，但这并不是蝉小队的真实目的。游记只是我们收集结构化数据 (简称碎片) 的方式，然后再用碎片重新搭建结构化的旅行指南。或者我们换一个更容易理解的说法：wiki 形态的移动版《lonely planet》。

在这颗蓝色的孤独行星上，还从来没有出现过一款真正像样的，用 UGC 来搭建的结构化旅行指南。相比传统的路书，它更全面，更丰富，更适合在旅行途中使用；相比游记攻略，它有更高得多的查询效率。但这样的产品是不存在的——没错，目前还不存在——蝉小队想拿到这项成就。

我们都知道，LP 是旅行者的圣经。但就像 wikipedia 早已超越了大英百科全书，用不断滚动的海量游记碎片来组装的旅行指南，同时又借鉴了 LP 优秀的信息组织方式，将会为旅行者提供生动，多角度，更新维护飞快，图文并茂 (甚至包括视频) 的目的地信息服务。

蝉游记发布一年，产生游记数万篇，旅行相片数百万张，已经积累了足够的碎片。接下来，令人惊讶的旅行指南即将现身。

关于“旅行福利”

不旅行的人怎么做得好旅行产品？

为了身体力行，蝉小队实行全员旅行福利。每人每月有 1 天带薪旅行假期，1000 元旅行补贴，最多可累计 6 个月使用，不用作废。相当于每半年至少有一次长途旅行机会。

关于其他福利

-每年 13 薪，全额缴纳社保公积金 -午餐由家政阿姨烹饪，无须外出觅食，如果你坚持外出觅食则会获得 350 元的餐补 -敞开供应零食饮料下午茶 (有神器“飞利浦空气炸锅”加持！) 并支持自选采购模式 -春节放假 2 周 -3 个单身妹子 (此处应有掌声) -没有周报，没有考核，没有 KPI，很少开会，但有严格的个人计划管理 -养过叫“貂蝉”的灰龙猫，啃烟头自杀了；又养了叫“恶魔萌”的赛级拉布拉多犬，造成接近 8000 元破坏后，即将送人；我司 CEO 不死心，正在构思下一只团队宠物……

关于蝉小队

目前只有 6 个人……你没看错，只有 6 个人。

联合创始人纯银 (郭子威)，之前在网易做了 5 年的内容和产品部门总监，最近为不再萌而烦恼。联合创始人 Quake(王益善)，12 年编程史的 Ruby 工程师，经常敲着敲着代码就自言自语说“有种想哭的感觉”。全能工程师凌晔，一人拿下了蝉游记的网站与 iOS 客户端。以及 UI 设计师菲仔，运营妹子莱拉与宝玉。

顺带为莱拉妹子打个征男盆友小广告：http://chanyouji.com/trips/46202

还有一只损坏了 2 块硬盘，1 台电脑，2 组沙发，1 个茶几，一整排窗帘，并在地板上刨出 3 个大坑的恶魔般的拉布拉多犬。

温情告知

-在上海浦东的民宅办公，不喜欢太正经的氛围 -闲聊时的口味略重，格调略低，腐女们略嚣张 -蝉小队政治立场偏右

招聘职位

▎Android 工程师

通常情况下同一款应用的 iOS 版本会比 Android 版更流畅，更精致，但我们想试试，能不能用更强大的蝉游记 Android 版来打败自家的 iOS 版本。

基本要求： -1 年以上 Android 平台开发经验，有作为主力工程师完整开发过一个以上 Android 应用的经验 -精通 Android UI 布局，精通不同分辨率适配，熟悉多线程、SQLite 数据库等操作 -精通 HTTP 通讯协议，有 Restful API 使用经验，熟悉 JSON 数据格式 -熟悉 Android OS 系统体系结构、framework 以及底层库等，熟悉 Android 的各种开源组件和 Android 界面设计规范 -有 Google Play，360，豌豆夹等国内外主要市场的上架经验 -熟悉 git，了解 gitflow

加分项： -有图片、音频、视频、地图类应用开发经验 -有 Unix 环境经验，日常使用 Unix 环境开发 -有开源的 Android 项目 -会使用 PhotoShop 或者其他图片处理软件进行简单操作 -熟悉 Ruby(豪大大地加分) 或者 Python 语言 -果黑...

应聘须知：请提供你负责的上架 App 名称和下载地址，并请预先体验蝉游记 iOS 版本，总结其中的功能或者交互在 Android 上实现的难点，或提出在 Android 上有更好的实现方式。如有 Github 账户/个人微博/博客地址也请一并告知。

▎Android 产品经理

蝉游记的 iOS 版口碑不错，我们希望能在这基础上做出更好的 Android 版，争取拿个奖啥的，而不仅仅是冲个量。

基本要求： -2 年以上产品资历 -负责过一款以上的上架 Android 应用设计 -交互设计挥洒自如，在蝉小队，PM 就是交互 -承担繁琐的测试工作（iOS 版的测试用例有 400 多条），在蝉小队，PM 就是 QA

加分项： -Android 生态与 iOS 生态双修 -有过一次以上长途自由行的经历

应聘须知：请告知你的 Android 手机型号，介绍你负责的 Android 应用，提名 10 款你眼中的最佳 Android 应用，并回答你对蝉游记进行数据结构化的手段与效果的看法。个人微博/博客地址也请一并告知。

又及，有意转型产品经理的交互设计师也可以试试这个职位。

▎目的地运营

负责结构化旅行指南的制作，游记审核，官微运营与用户关系。希望你是一本活的路书，或者接近这个效果。即便不是，在这个岗位上工作半年后，你就是一本活的路书。

基本要求： -有过三次以上长途自由行的经历，长时间不旅行有可能憋死 -习惯在出行前做足功课，制定超详细的日程计划 -好笔头，爱写字，有长期经营的微博、博客或空间 -英文不错，浏览 TripAdvisor.com 的点评内容无障碍

加分项： -有过出国旅行的经历 (去得越多越远就越赞) -写过不少游记，若有攻略更佳 -整理控 -App 大玩家，追逐一切新潮应用 -很多朋友评价你“外向活泼”或“亲和力强”或“耐心细致” -在社交网络有一大群粉丝

应聘须知：请介绍过往的旅行经历，未来最想去的 3 个目的地，提供一份由你亲手制定的旅行日程计划文档，以及个人微博/博客/空间地址。

又及，运营人员将分两到三批招聘。如果你希望明年初再应聘，也可以先发一份简历在我这里存档，届时会主动跟你联系。

▎市场营销

接下来的营销重心主要是拉升 App 下载量，也包括提升用户活跃度，外部业务合作，以及从无到有地培植旅行指南的品牌。

基本要求： -1 年以上 App 推广资历 -对安卓渠道了如指掌，有自己的人脉关系 -擅长推广物料设计 (当然是你构思卖点与文案，再协调设计师来设计) -长期保持严谨的数据分析习惯

加分项： -丰富的广告投放经验 -有过一次以上长途自由行的经历

应聘须知：请介绍过去值得一提的推广业绩，提供你负责的推广物料样例，活动样例，并告知个人微博/博客地址。

又及，我们会根据应聘者的情况来灵活确定这个职位的权责与 Title。

▎行政

创业团队都需要这样一个妹子，负责日常行政事务，帮新加入的员工办理社保，记录报销和时序账，偶尔还要跑一下工商税务啥的。但蝉小队这些方面的事儿又不多，所以我还希望她能负责一定的内容运营工作，甚至未来转职运营也说不定。

基本要求： -85-90 年的妹子，2 年以上行政/人事/会计相关工作经验 -有会计从业资格证 -好笔头，爱写字，有长期经营的微博、博客或空间 -严格来说，我们这次需要的不是一个行政人事财务老手，而是除了能做好那些本职之外，还对运营工作兴致勃勃并且力能胜任的人

加分项： -美少女 -有过一次以上长途自由行的经历

应聘须知：比对着“目的地运营”职位的应聘须知，提供力所能及的材料，并告知个人微博/博客地址。

▎UI 设计师（存档）

此次招聘并不含 UI 设计岗位，但蝉小队在半年内还会增加另一位 UI 设计师。所以有意在春节前后换工作的朋友，不妨先发一份简历在我这里存档，届时会主动跟你联系。事实上，我们希望能对一整个蝉游记进行重新设计，而不是在旧框架上修修补补。

基本要求： -3 年以上 UI 设计资历，其中 App 设计不少于 1 年 -有独立制定产品视觉基调的成功案例 -手绘功底不俗，擅长 icon 设计 -App 大玩家，追逐一切新潮应用

加分项： -Android 生态与 iOS 生态双修 -对产品交互设计，甚至是功能策划的想法多多，希望参与产品的更多环节 -摄影高手 -有过一次以上长途自由行的经历

应聘须知：请提供包括 icon 在内的视觉作品集，并告知个人微博/博客地址。

应聘方式请发邮件到 firecicada@gmail.com，邮件标题注明应聘职位。如符合条件，会在 5 个工作日内收到回复。

蝉游记网站的部署 Nginx,Unicorn,Capistrano,OOB,Graceful Restart

quakewang — Thu, 27 Jun 2013 12:15:50 +0800

蝉游记（ http://chanyouji.com ）网站之前用 Nginx+Passenger+ 自制 script 来部署，随着用户增多，移动 app 的 api 调用增加，服务器增多和无缝部署重启的需求，转移到了 Nginx+Unicorn+Capistrano，写篇博客记录一下各种细节和需要注意的地方。

Nginx 的配置

gzip  on;
#开启gzip，同时对于api请求的json格式也开启gzip
gzip_types application/json;

#每台机器都运行nginx+unicorn，本机用domain socket，方便切换
upstream ruby_backend {
    server unix:/tmp/unicorn.sock fail_timeout=0;
    server 10.4.8.34:4096 fail_timeout=0;
    server 10.4.3.8:4096 fail_timeout=0;
}

#用try_files方式和proxy执行rails动态请求
server {
    listen       80;
    server_name  chanyouji.com;
    root         /www/youji_deploy/current/public;

    try_files $uri/index.html $uri.html $uri @user1;

    location @user2 {
      proxy_redirect     off;
      proxy_set_header   Host $host;
      proxy_set_header   X-Forwarded-Host $host;
      proxy_set_header   X-Forwarded-Server $host;
      proxy_set_header   X-Real-IP        $remote_addr;
      proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
      proxy_buffering    on;
      proxy_pass         http://ruby_backend;
   }
}

#用不同的域名提供静态资源服务，减少主域名带来的cookie请求和方便做cdn源
server {
    listen       80;
    server_name  cdn.chanyouji.cn cdnsource.chanyouji.cn;
    root         /www/youji_deploy/current/public;

    location ~ ^/(assets)/  {
      root /www/youji_deploy/current/public;
      gzip_static on; # to serve pre-gzipped version
      expires max;
      add_header Cache-Control public;
    }
}

unicorn.rb 的配置

worker_processes 6

app_root = File.expand_path("../..", __FILE__)
working_directory app_root

# Listen on fs socket for better performance
listen "/tmp/unicorn.sock", :backlog => 64
listen 4096, :tcp_nopush => false

# Nuke workers after 30 seconds instead of 60 seconds (the default)
timeout 30

# App PID
pid "#{app_root}/tmp/pids/unicorn.pid"

# By default, the Unicorn logger will write to stderr.
# Additionally, some applications/frameworks log to stderr or stdout,
# so prevent them from going to /dev/null when daemonized here:
stderr_path "#{app_root}/log/unicorn.stderr.log"
stdout_path "#{app_root}/log/unicorn.stdout.log"

# To save some memory and improve performance
preload_app true
GC.respond_to?(:copy_on_write_friendly=) and
  GC.copy_on_write_friendly = true

# Force the bundler gemfile environment variable to
# reference the Сapistrano "current" symlink
before_exec do |_|
  ENV["BUNDLE_GEMFILE"] = File.join(app_root, 'Gemfile')
end

before_fork do |server, worker|
  # 参考 http://unicorn.bogomips.org/SIGNALS.html
  # 使用USR2信号，以及在进程完成后用QUIT信号来实现无缝重启
  old_pid = app_root + '/tmp/pids/unicorn.pid.oldbin'
  if File.exists?(old_pid) && server.pid != old_pid
    begin
      Process.kill("QUIT", File.read(old_pid).to_i)
    rescue Errno::ENOENT, Errno::ESRCH
      # someone else did our job for us
    end
  end

  # the following is highly recomended for Rails + "preload_app true"
  # as there's no need for the master process to hold a connection
  defined?(ActiveRecord::Base) and
    ActiveRecord::Base.connection.disconnect!
end

after_fork do |server, worker|
  # 禁止GC，配合后续的OOB，来减少请求的执行时间
  GC.disable
  # the following is *required* for Rails + "preload_app true",
  defined?(ActiveRecord::Base) and
    ActiveRecord::Base.establish_connection
end

GC OOB

这篇 newrelic 的文章解释很清楚： http://blog.newrelic.com/2013/05/28/unicorn-rawk-kick-gc-out-of-the-band/ 就是将 GC 延迟到用户请求完成以后，这样就会缩短响应时间，配合现成的 gem unicorn-worker-killer 也不用担心内存爆掉。

在 config.ru 里面配置：

require 'unicorn/oob_gc'
require 'unicorn/worker_killer'
#每10次请求，才执行一次GC
use Unicorn::OobGC, 10
#设定最大请求次数后自杀，避免禁止GC带来的内存泄漏（3072～4096之间随机，避免同时多个进程同时自杀，可以和下面的设定任选）
use Unicorn::WorkerKiller::MaxRequests, 3072, 4096
#设定达到最大内存后自杀，避免禁止GC带来的内存泄漏（192～256MB之间随机，避免同时多个进程同时自杀）
use Unicorn::WorkerKiller::Oom, (192*(1024**2)), (256*(1024**2))

require ::File.expand_path('../config/environment',  __FILE__)
run Youji::Application

Capistrano 部署脚本

set :unicorn_config, "#{current_path}/config/unicorn.rb"
set :unicorn_pid, "#{current_path}/tmp/pids/unicorn.pid"

namespace :deploy do
  task :start, :roles => :app, :except => { :no_release => true } do
    run "cd #{current_path} && RAILS_ENV=production bundle exec unicorn_rails -c #{unicorn_config} -D"
  end

  task :stop, :roles => :app, :except => { :no_release => true } do
    run "if [ -f #{unicorn_pid} ]; then kill -QUIT `cat #{unicorn_pid}`; fi"
  end

  task :restart, :roles => :app, :except => { :no_release => true } do
    # 用USR2信号来实现无缝部署重启
    run "if [ -f #{unicorn_pid} ]; then kill -s USR2 `cat #{unicorn_pid}`; fi"
  end
end

完成这些改进以后，部署蝉游记的新版本就只用输入 cap production deploy，然后就可以喝茶去了，也不用担心用户在重启动的时候会有短期卡死的问题 :)

补 2 张图： new relic 的监控图，和启用 OOB 之前相比，平均响应时间从 100ms 左右下降到了 90ms 左右：

服务器的内存和 CPU 使用：

都来聊聊人生污点吧

quakewang — Sun, 06 Jan 2013 10:54:53 +0800

在生产数据库服务器上执行 delete 语句的时候，很开心地少打了一个 where 条件，导致整个表被清空。

防火墙配置限制 ip 访问，复制粘贴的时候出错，导致数据库服务器断开了所有的链接。

和同事一起维护，他用 root 账户清理一些文件，以为在/tmp 目录下面，执行了 rm . -rf，看到屏幕飞快地刷，我忽然有一种很不好的感觉，赶紧喊 ctrl+c，然后过 1 秒等他明白过来狂按的时候，才发现服务器的 IO 性能太好有时候也是一种错误...

本人亲历...楼下继续...

quakewang

好像发现 ruby china 的一个 bug

性能优化案例分析之二：时间区域查询的性能优化

背景

分析过程

第一步：EXPLAIN

第二步：理解执行计划

第三步：分析数据

解决方案

扩展

性能优化案例分析之一：软删除是慢查询的罪魁祸首？

背景

分析过程

第一步：EXPLAIN

第二步：理解执行计划

第三步：分析数据

解决方案

扩展

counter_cache + foreign_key + MySQL = DEADLOCK??

Ruby 2.4 哈希表 (Hash) 的变化

Ruby 是如何实现哈希表的

Ruby 2.4 之前的 2 个小细节优化

Ruby 2.4 Hash 的改变

Google App Engine 支持 Ruby 了

自制监控服务接收 NewRelic RPM 数据

[上海] 蝉游记 / 携程周末 招聘 Ruby 工程师

团队介绍

工作职责

基本要求

加分项

工作地点

福利待遇

Ruby 中的函数式编程

什么是函数式编程

函数式编程有什么好处

请先做道题

Ruby 中的函数式编程

不更新变量

不依赖外部变量

Currying

回到最初的题目

程序员的好玩具 - Lego EV3

Redis 作为缓存服务器的配置

Redis 配置

Redis 监控

优化 Rails 的缓存配置

性能监控的好工具 - NewRelic 简介

Ruby 程序员写 Swift 毫无压力

总结 Web 应用中常用的各种 Cache

1. 客户端缓存

2. Nginx 缓存

3. 整页缓存

4. 片段缓存

5. 数据查询缓存

6. 数据库缓存

升级 Ruby 2.1 以及 GC 调整

周末活动介绍 Prawn 的 Slide

[免费] 转让 RubyConfChina 门票一张

[上海] 蝉游记 - 一大波职位正在向你靠近

写在前面的话

以下是正文

关于蝉游记 lv2

关于“旅行福利”

关于其他福利

关于蝉小队

温情告知

招聘职位

▎Android 工程师

▎Android 产品经理

▎目的地运营

▎市场营销

▎行政

▎UI 设计师（存档）

蝉游记网站的部署 Nginx,Unicorn,Capistrano,OOB,Graceful Restart

都来聊聊人生污点吧

[上海] 蝉游记 / 携程周末招聘 Ruby 工程师