taojay315 (Jerry)

ngx_mruby Benchmark

taojay315 — Fri, 18 Mar 2016 12:06:02 +0800

看来还是要简单说明一下，要不然我看所有人都要纠结到我的测试准不准上去了。

这个测试并不是要搞个大新闻，哇 ruby 新出了一个性能提升 10 倍，并不是这样，没有银弹。

mruby 跟 ruby 完全不是一回事，放在一起只是对照。

测试肯定不准，sinatra 和 rack 配置一下性能会更好，nginx 配置一下性能也更好，不过可以参考官方 benchmark，不在一个数量级上是肯定的。这个结果只是为高并发的工具箱里加一个工具。

比如一个项目压力很大，但是可能只有那么一两个请求压力大，以前的解决方案可能是拆项目，换语言等方式解决。现在可以考虑把压力大但是不复杂的请求用 mruby 实现一下然后做个微服务出来。

mruby 跟 ruby 不是一回事不仅仅是运行方式不一致，支持也不一致，至少目前用 mruby 处理复杂业务是不太现实的。每次引入新的 gem 或者有其他底层修改都需要重新编译 nginx。

========================

用例：在 redis set 里面 spop 一条返回 json。

测试：ab -c100 -n15000 http://localhost:9292/

# sinatra

Requests per second:    1020.89 [#/sec] (mean)
Time per request:       97.953 [ms] (mean)

# Only rack

Requests per second:    1020.89 [#/sec] (mean)
Time per request:       97.953 [ms] (mean)

#  ngx_mruby

Requests per second:    14339.08 [#/sec] (mean)
Time per request:       6.974 [ms] (mean)

不准确，只有参照价值。
mruby 跟 ruby 完全不是一回事，放在一起只是做个对照，mruby 现阶段的直面对手应该是 lua.

Ruby Hook Methods

taojay315 — Thu, 14 Jan 2016 00:37:36 +0800

Hook Methods 一般译为钩子方法，可以理解为当触发了某个条件执行的方法。例如我们常见的 method_missing。

Method 相关

respond_to_missing?: 当尝试查看一个 missing 的方法时执行。
method_missing: 当调用一个不存在的方法时执行。
method_added: 当定义一个方法时执行
method_removed: 当一个方法被移除时执行
singleton_method_added: 当添加一个 singleton 方法时执行。
singleton_method_removed: 当一个 singleton 方法被移除时执行。
method_undefined: 当一个方法被 undefined 的时候执行，undef 和 remove 的区别在于当你在子类中你可以 undef 掉从父类继承而来的方法，而 remove 则不可以删除定义在父类中的方法。在父类中无论是使用 undef 和 remove 子类都无法继续使用这些方法。
singleton_method_undefined: 当一个 singleton 方法被 undefined 时刻执行。

示例代码：

# respond_to_missing?
class Base
  def respond_to_missing?(sym, *args)
    true
  end
end
Base.new.respond_to?(:missing_method)
# 这个跟重写respond_to?的区别主要在于使用下面这个方法
Base.new.method(:missing_method)
# => #<Method: Base#missing_method>

# method_missing
class Base
  def method_missing(method_name)
    puts method_name
  end
end
Base.new.missing_method
# => missing_method

# method_added

class Base
  def self.method_added(method_name)
    puts method_name
  end

  def missing_method
  end
end
# => missing_method
Base.class_eval { def missing_method2;end }
# => missing_method2

# method_removed
class Base
  def self.method_removed(method_name)
    puts method_name
  end
end    
Base.class_eval { remove_method :missing_method }
# => missing_method

# method_undefined
class Base
  def self.method_undefined(method_name)
    puts method_name
  end
end    
Base.class_eval { undef_method :missing_method }
# => missing_method

# singleton_method_added/removed/undefined
class Base
  def self.singleton_method_added(method_name)
    puts method_name
  end

  def self.missing_method
  end

  def Base.missing_method1
  end
end
def Base.missing_method2
end

# => singleton_method_added
# => missing_method
# => missing_method1
# => missing_method2

Class/Object相关

inherited: 当被继承时执行。
initialize_copy: 当调用 initialize_clone 和 initialize_dup 时执行。
initialize_dup: 当调用 dup，返回 dup 结果前时执行。
initialize_clone: 当调用 clone，进行 frozen 判断和返回 clone 结果之前执行。

介绍这几个方法之前我们先要了解一下 dup 和 clone 的区别，主要有以下两点：

dup 不会复制 frozen 状态，clone 会。
dup 不会复制 singleton class，clone 会。

# inherited
class Base
  def self.inherited(sub)
    puts sub.name
  end
end
class Sub < Base
end

# => Sub

# initialize_*
class Base
  def initialize_copy(other)
    puts 'initialize_copy'
    super
  end
  def initialize_dup(other)
    puts 'initialize_dup'
    super
  end
  def initialize_clone(other)
    puts 'initialize_clone'
    super
  end
end
Base.new.dup    
# => initialize_dup                  
# ＝> initialize_copy
Base.new.clone                      
# => initialize_copy
# => initialize_clone

Modules 相关

included: 当 include 时执行。
append_features: 当 include 时执行。
prepended: 2.0 新增 prepend 的时候执行。
prepend_features：跟上面的 append_feature 可以一同理解。
extend_object: 当被 extend 时执行。
extended: 当被 extend 时执行。
const_missing: 当有常量丢失时执行。

首先来说，对于 include，prepend 这两者和 extend 的关系很容易区分。include 和 prepend 的区别在于对祖先链的修改方式，进一步影响方法的查找流程。

参考下面的例子：

module M
  def hello
    puts 'Hello from M'
    super
  end
end

module N
  def hello
    puts 'Hello from N'
  end
end

class C
  include N
  prepend M
  def hello
    puts 'hello from C'
    super
  end
end
C.new.hello
#=> Hello from M
#=> hello from C
#=> Hello from N

其中 included 和 append_features 是一组，prepended 和 prepend_features 是一组，extended 和 extend_object 是一组。

以 included 和 append_features 来说，append_features 这个方法是真正把 module 里的代码混入到 include 此 module 的地方，而 included 仅仅是在完成混入之后执行的一个回调，下面是一个伪示例：

module M
  def self.append_features(mod)
    mod.class_eval {def new_method;puts 'say hi!';end}
  end

  def self.included(mod)
    puts 'included'
    mod.new.new_method
  end

  def self.const_missing(const_name) # 当常量丢失时执行
    puts const_name
  end

  MissingConst # 访问不存在常量
end
# => MissingConst
M::MissingPerson
# => MissingPerson # 访问不存在常量

对于 prepend 和 extend 两组来说也是如此。

Marshal 相关

marshal_dump: 当 Marshal.dump(@obj) 时执行。
marshal_load: 当 Marshal.load(@obj) 时执行。

class C
  attr_accessor :arrs, :d_arrs
  def marshal_dump
    Marshal.dump(arrs)
  end

  def marshal_load(data)
    self.d_attrs = Marshal.load(data)
  end
end

k = C.new
k.arrs = [1,2,3,4,5]
k2 = Marshal.load(Marshal.dump(k))
k2.d_arrs 
# => [1,2,3,4,5]
k2.arrs 
# => nil

Coercion 相关

coerce: 当使用一个二元操作符的时候会在第二个参数上触发，当我们重载运算符的时候很有用。
to_*系列方法：这些方法虽然看起来不像，但其实很多时候都会被触发：

# coerce
class C
  def coerce(n)
    puts n
    [n,5]
  end
  def to_s
    "CCCC"
  end
  def to_int
    3
  end
  def to_proc
    Proc.new {|i| puts i}
  end
end
3*C.new
#=> 3
#=> 15
"#{C.new}" #=> CCCC 会触发to_s
[1,2,3,4,5][C.new]                                               
# => 4 触发to_int
[1,2,3,4,5].each(&C.new) # to_proc
# => 1
# => 2
# => 3
# => 4
# => 5

Ruby 常量查找 (译)

taojay315 — Mon, 11 Jan 2016 23:56:15 +0800

不好意思没注意到，跟这篇重复了，管理员看到顺手帮我删了吧。 https://ruby-china.org/topics/26890

注：此文翻译整理自https://cirw.in/blog/constant-lookup ，推荐关注，pry 主要贡献人

翻译的难免有错，请见谅。

使用常量很简单，理解如何查找常量的很麻烦。

虽然一句话就可以说清楚常量查找，依次在 Module.nesting, Module.nesting.first.ancestors 中查找，如果 Module.nesting.first 是 nil，则在 Object.ancestors 中查找。，但是为了更好的理解，我们还是举几个例子吧。

Module.nesting

Ruby 首先会根据词法作用域 (lexical scope) 周围的 module 或者 classes 的关联的常量来查找：

module A
  module B; end
  module C
    module D
      B == A::B
    end
  end
end

上面的例子里在 D 中的 B 首先会查找：A::C::D::B (不存在), 然后 A::C::B (不存在), 最后 A::B (找到了)。

跟 ruby 里的其他东西一样，查找常量的 namespace chains 也是在运行时通过 Module.nesting 可以实现自省的（运行时知道自己的 Module.nesting）：

module A
  module C
    module D
      Module.nesting == [A::C::D, A::C, A]
    end
  end
end

如果你尝试过用简写的声明方式来重打开一个 module，你可能已经注意到不使用完整的 namespace 是无法访问其他常量的。这是因为外面的 namespace 并没有添加到 Module.nesting 当中：

module A
  module B; end
end

# 错误
module A::C
  B
end

# 正确
module A
  module D
    B
  end
end
# NameError: uninitialized constant A::C::B

上面错误的例子中，如果要使用 B，那么 Module.nesting 里必须包含 A, 但是上面的 nesting 里只有 [A::C]

Ancestors

如果在 Module.nesting 中找不到，Ruby 就会在当前打开 class 或者 module 的祖先中查找。

class A
  module B; end
end

class C < A
  B == A::B
end

当前打开是指最里面的 class 或者 module，例如上面查找 B 的 C。一个常见的误解就是常量查找会使用 self.class，例如上面也许觉得 B 应该查找 C::B，但实际上并不会这样查找，参考下面的例子。

class A
  def get_c; C; end
end

class B < A
  module C; end
end

B.new.get_c #self.class是B，但是并不会查找B::C 当前打开类是A，
# NameError: uninitialized constant A::C

Object::

在顶级作用域的时候，Module.nesting 是 []，所以常量直接在当前打开的 class 和他的祖先里查找，虽然你看不到，但是顶级作用域里的当前打开类是 Object。

class Object
  module C; end
end
C == Object::C

虽然还没有说，但是你也应该注意到，新定义的常量也会在当前打开类里进行定义，所以顶级作用域里定义的常量也会在 Object 里进行定义：

module C; end
Object::C == C

这个就解释了为什么在顶级作用域里定义的常量在哪里都可以使用，因为在 ruby 里大部分类都是 Object 的子类，所以 Object 总是在其他类的祖先链里，所以在顶级作用域里定义的常量在其他地方都可以使用。

所以如果你使用过 BasicObject(不是 Objet 的子类)，你会注意到你在 BasicObject 内部无法访问顶级作用域的常量。

class Foo < BasicObject
  Kernel
end
# NameError: uninitialized constant Foo::Kernel

如果你想在这种情况下使用，可以使用::Kernel 来访问 Object::Kernel。

Ruby 假设你会把 module 混入到继承自 Object 的 class 之中，所以如果当前打开的是一个 module，也会把 Object 添加到祖先链之中。所以可以在 module 中使用顶级作用域的常量。

module A; end
module B;
  A == Object::A
end

class_eval

正如上面提到的，常量会查找当前打开的类或者 module，当前打开取决于周围的 class 或者 module 关键字，所以，如果你使用 class_eval 或者 module_eval 来执行 block，这个并不会修改当前打开类。还是会在 block 定义的作用域内查找。

class A
  module B; end
end

class C
  module B; end
  A.class_eval{ B } == C::B
end

不过略复杂的事实是，如果你使用字符串来 eval，在 class_eval 的情况下，Module.nesting 中会包含自己的 class，在 instance_eval 的情况下，Module.nesting 中则会包含这个 object 的 singleton class。

class A
  module B; end
end

class C
  module B; end
  A.class_eval("B") == A::B
end

其他细节

最后我想指出，你在一个 class 的 singleton 里是无法访问在 class 内定义的常量。

class A
  module B; end
end
class << A
  B
end
# NameError: uninitialized constant Class::B

这是因为 singleton class 的祖先链中并不包含自身的 class，直接从 Class 开始。

class A
  module B; end
end
class << A; ancestors; end
[Class, Module, Object, Kernel, BasicObject]

相似的情况下，还需要指出已经在 Module.nesting 里的 class 的父类并不会出现在 Module.nesting 之中，如下面的 A。

class A
  module B; end
end

class C < A
  class D
    B
  end
end
# NameError: uninitialized constant C::D::B

总结

常量查找并不难，只需要记住查找词法包围的 class 和 module，你可以使用 Module.nesting 里的第一个值来当作当前打开类或者模块，如果这个值为空，则当前打开类是 Object。

下面的代码模拟了 ruby 内部的常量查找方式，你会注意到我使用字符串作为 binding.eval 的变量所以 Module.nesting 是 binding 的 object 而不是 block。

class Binding
  def const(name)
    eval <<-CODE, __FILE__, __LINE__ + 1
      modules = Module.nesting + (Module.nesting.first || Object).ancestors
      modules += Object.ancestors if Module.nesting.first.class == Module
      found = nil

      modules.detect do |mod|
        found = mod.const_get(#{name.inspect}, false) rescue nil
      end
      found or const_missing(#{name.inspect})
    CODE
  end
end

(翻译完)

其他

实际上常量查找是很好玩的一个过程，可以参考一下 Rails 实现 const_missing 和 const_get 的方法。

可以解决诸多疑惑，例如：

class Person
end

String.const_get(:Person) # Person
String::Person # Person
String::Person::String # String

Rails Log Process

taojay315 — Tue, 29 Sep 2015 19:20:48 +0800

最近研究了一下整理 Rails 的日志，简单整理下。

使用工具包括：

logstash
lograge
elasticsearch

0. 准备

如果没有修改过任何配置，rails 的日志大概是这样的

Started POST "/users" for ::1 at 2015-09-28 15:46:22 +0800
Processing by Devise::RegistrationsController#create as HTML
  Parameters: {"utf8"=>"✓", "authenticity_token"=>"m/JixAv0ZmXTRLn1mmFGKNF/1MQgb5iXqPThmc3S23B7eiYfCmzwDXALr5yrw9v0dUWdkGVEkGzt8Qa2Q9vlFQ==", "user"=>{"email"=>"user@example.com", "password"=>"[FILTERED]", "password_confirmation"=>"[FILTERED]"}, "commit"=>"Sign up"}
   (0.1ms)  begin transaction
  User Exists (0.1ms)  SELECT  1 AS one FROM "users" WHERE "users"."email" = 'user@example.com' LIMIT 1
   (0.1ms)  rollback transaction
  Rendered /usr/local/var/rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/gems/devise-3.4.1/app/views/devise/shared/_links.html.erb (1.6ms)
  Rendered /usr/local/var/rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/gems/devise-3.4.1/app/views/devise/registrations/new.html.erb within layouts/application (11.1ms)
Completed 200 OK in 148ms (Views: 51.5ms | ActiveRecord: 0.3ms)

这个时候使用的 logger 是 ActiveSupport 里提供的默认 logger。

Rails log 机制是通过 pub/sub 来实现的，比如 ActiveRecord::LogSubscriber，还是很方便重新改写的。

（关于 Notification 可以翻看以前的一篇文章。ActiveSupport Notifications）

了解这些基础之后让我们假设一个我们需要的数据格式（伪 model）：

class SQL
  belongs_to :request
  attributes :uuid # 用来跟request关联的id
  attributes :session_id # 用来跟request关联的id
  attributes :duration # 时间
  attributes :name # 存储对应的模型名称
  attributes :message # 存储对应的SQL语句
  attributes :type # 区别其他两种类型
end

class ExceptionStack
  belongs_to :request
  attributes :uuid # 用来跟request关联的id
  attributes :session_id # 用来跟request关联的id
  attributes :message # 错误信息
  attributes :error # 错误类
  attributes :backtrace # 异常栈
  attributes :status # 返回的状态
  attributes :handler # 处理的方法
  attributes :type # 区别其他两种类型
end

class Request
  attributes :uuid # 每一次请求的唯一标志
  attributes :session_id # 一次session的id
  attributes :method # HTTP Verb
  attributes :path # 请求地址
  attributes :format # 请求格式
  attributes :controller # 对应controller
  attributes :action # 对应action
  attributes :status # 返回状态
  attributes :duration # 时间
  attributes :view # 渲染页面时间
  attributes :db # 处理数据库时间
  attributes :type # 区别其他两种类型
  attributes :host # 主机地址
  attributes :remote_ip # 请求IP
  attributes :origin # 来源请求的页面
  attributes :user_agent # 用户浏览器信息
  attributes :@timestamp # 时间
  attributes :message # 请求概述
end

1. 格式化 Rails 日志

1.1 Request 日志

先加 lograge 和 logstash-event 到 Gemfile

gem 'lograge'
gem 'logstash-event'

然后在 application.rb 里先简单配置一下：

config.lograge.enabled = true
config.lograge.formatter = Lograge::Formatters::Logstash.new
config.colorize_logging = false # 关闭彩色显示，会产生很多不适合阅读的字符。

这个时候输出的结构大概是：

{
    "method": "POST",
    "path": "demo/auth/sessions",
    "format": "json",
    "controller": "demo/auth/sessions",
    "action": "create",
    "status": 401,
    "duration": 27.2,
    "view": 0.22,
    "db": 11.32,
    "@timestamp": "2015-09-29T10:53:14.766Z",
    "@version": "1",
    "message": "[401] POST demo/auth/sessions (demo/auth/sessions#create)"
}

距离我们要的数据还缺很多信息，根据 lograge 的文档，需要先在 application 把需要的数据加进来

# application_controller.rb
def append_info_to_payload(payload)
  super
  payload[:uuid] =  request.uuid
  payload[:session_id] = request.cookie_jar['_session_id']
  payload[:host] = request.host
  payload[:remote_ip] = request.remote_ip
  payload[:origin] = request.headers['HTTP_ORIGIN']+request.headers['ORIGINAL_FULLPATH']
  payload[:user_agent] = request.headers['HTTP_USER_AGENT']
end

然后就可以在 application.rb 自定义一下这些内容了：

#application.rb
config.lograge.custom_options = lambda do |event|
  {
    uuid: event.payload[:uuid],
    session_id: event.payload[:session_id],
    type: 'request',
    host: event.payload[:host],
    remote_ip: event.payload[:remote_ip],
    origin: event.payload[:origin],
    user_agent: event.payload[:user_agent]
  }
end

这样请求的格式就正确了。

1.2 SQL 日志

SQL 的日志默认是通过 ActiveRecord::LogSubscriber 来记录的，这个会包含格式化 SQL 语句等功能，但是我们想把他转换成 json，适合通过 logstash 收集进 elasticsearch。

我用了一种很取巧的手段：

#config/initializers/sql_log.rb
# 先把默认的subscriber去掉。
Lograge.module_eval do
  ActiveSupport::LogSubscriber.log_subscribers.each do |subscriber|
    case subscriber
    when ActiveRecord::LogSubscriber
      unsubscribe(:active_record, subscriber)
    end
  end
end

# 自己实现一个subscriber
module SQLLog
  class LogSubscriber < ActiveSupport::LogSubscriber
    IGNORE_PAYLOAD_NAMES = ["SCHEMA", "EXPLAIN"]

    def self.runtime=(value)
      ActiveRecord::RuntimeRegistry.sql_runtime = value
    end

    def self.runtime
      ActiveRecord::RuntimeRegistry.sql_runtime ||= 0
    end

    def self.reset_runtime
      rt, self.runtime = runtime, 0
      rt
    end

    def initialize
      super
    end

    def render_bind(column, value)
      if column
        if column.binary?
          # This specifically deals with the PG adapter that casts bytea columns into a Hash.
          value = value[:value] if value.is_a?(Hash)
          value = value ? "<#{value.bytesize} bytes of binary data>" : "<NULL binary data>"
        end

        [column.name, value]
      else
        [nil, value]
      end
    end

    def sql(event)
      self.class.runtime += event.duration
      return unless logger.debug?

      payload = event.payload

      return if IGNORE_PAYLOAD_NAMES.include?(payload[:name])

      unless (payload[:binds] || []).empty?
        binds = "  " + payload[:binds].map { |col, v|
          render_bind(col, v)
        }.inspect
      end
      ids = Thread.current[:log_uuid_session_id] || Array.new(2)
      log = {
        name: payload[:name],
        duration: event.duration.round(1),
        binds: binds,
        message: payload[:sql],
        type: 'sql',
        uuid: ids[0],
        session_id: ids[1] }.to_json
      debug log
    end


    def logger
      ActiveRecord::Base.logger
    end
  end
end

# attach 到active_record上
SQLLog::LogSubscriber.attach_to :active_record

因为在这里面我想存储一下关联的 request 和 session，所以才有了ids = Thread.current[:log_uuid_session_id] || Array.new(2)。

如果不需要直接去掉就好，如果需要还需要在 application_controller 里记录一下：

# application_controller
before_filter :set_uuid_session_id

private

def set_uuid_session_id
  Thread.current[:log_uuid_session_id] = [request.uuid,request.cookie_jar['_session_id']]
end

这样可以很方便的看到一次请求产生了几条 db 请求。

1.3 异常日志

首先，rescue 所有的异常是很有争议的做法，不过我还是想对用户尽量屏蔽这些异常情况。

# application_controller.rb
rescue_from Exception, with: :generic_exception # 可能还有很多其他的异常rescue

def generic_exception(error)
  ids = Thread.current[:log_uuid_session_id]
  if error.is_a?(Class) && error <= Exception # 这里是因为有些时候会捕捉到例如RuntimeError这种情况。
    error_class = error.name
    error_message = error.name
    backtrace = []
  else
    error_class = error.class.name
    error_message = error.message
    backtrace = error.backtrace
  end
  log = { error: error_class, backtrace: backtrace, type: 'exception', status: 500, message: error_message, handler: 'generic_exception', uuid: ids[0],
          session_id: ids[1] }
  Rails.logger.error log.to_json
  render nothing: true, status: 500
end

通过上面的处理，适合输入到 logstash 的 json 格式日志算是准备好了。

2. 使用 logstash 收集 log

关于 logstash，还有多个 rails server 的情况，可以去参考 logstash 的文档，我就简单贴一下基本的配置：

input {
    stdin {}
  file {
    type=> 'application'
    path=>'~/Workspaces/demo/log/development.log'
    codec=>'json'
  }
}



output {
  stdout {}
  elasticsearch {
    cluster=> 'logstash'
    protocol => http
  }
}

不适合生产环境，如果使用多个集群还需要考虑使用 redis 来做中转，根据具体情况具体修改吧。

然后测试下：

elasticsearch -d
logstash -f sample.conf
rails s

随便访问几个网址，然后看一下 ES 里的数据：

curl -XGET "http://localhost:9200/logstash-2015.09.29/_search" -d'
{
  "sort": [
    {
      "@timestamp": {
        "order": "desc"
      }
    }
  ]
}'

默认情况下会使用 logstash-日期这种格式的 index。

至于如何显示如何处理，就是另一个 topic 了。

有很多细节地方还可以优化，例如把异常的 log 也使用 notification，把自己写的 notification 集成进 lograge 等，不过大体的思路还是这样的。