Suave’s Blog

Install

#sudo gem install railsbench 

(install path on my mac: /opt/local/lib/ruby/gems/1.8/gems/railsbench-0.9.0)

Configuration

1. set $RAILS_ROOT

eg. on my mac, edit ~/.bash_profile, add a path as below:

export RAILS_ROOT=”/Users/suave/rubyapps/rails_app”

2. #railsbench base

   or

   #eval ‘railsbench path’

3. #sudo railsbench postinstall 

Prepare your application

1. #railsbench install

(copy benchmarks.rb and benckmarks.yml to your rails_app/config, copy benchmarking.rb to your rails_app/config/environments)

2. edit benchmarks.yml as what you want

Run railsbench

#railsbench perf_run 100 -bm=all

(”all” is a target specified in benchmarks.yml)

Environments

RAILS_ROOT

          must be set to point to your rails app

RAILS_PERF_DATA

          performance data sets will be stored into this directory
            if not set, $HOME will be used

RAILS_PERF_RUNS

          the number of times perf_loop will run perf_bench on a single invocation
            if not set, 3 runs will be performed

RAILS_BENCHMARK_FILE

          perf_bench send it’s output to this file

See http://railsbench.rubyforge.org/ or README under your railsbench install path to know more

Ruby Performance Validator (RPVL) from Software Verification Ltd. (SVL)

You could check the product feature and  download a evaluated version from official website: http://www.softwareverify.com/ruby/profiler/index.html

SVL has lots of Ruby tools, eg. Ruby Bug Validator, Ruby Coverage Validator, Ruby Memory Validator and Ruby Thread Validator.

run rpvExample need Tk installed on your windows, so download Active Tcl (support various OS), type “require ‘tk’ “ in irb after installed Tcl/Tk, you could see “true”.

In RPVL, we could check CallStack, CallTree that are important to dissect the code.

Know more about RPVL, see the official tutorial that give you a introducion with a real example. At the last chapter, you could know how to use RPVL in Ruby on Rails.

Sun出品的XML Mark是我第一次接触performance test的内容，提到performance自然少不了记录时间，在XML Mark中Agent Thread在开始run的时候会用System.currentTimeMillis()记录当前时间，google一下，发现了下面这断文字：

Java 编程语言有一个计时方法，从早期版本起它就是标准 API 的一部分。 这个方法是 java.lang.System.currentTimeMillis()，它返回从 UTC 1970 年 1 月 1 日午夜开始经过的毫秒数。这个方法非常有用，特别 是它在各个版本的 Java 平台上都有。因此，在 上个月 我的 初始方面演示代码中，我使用了它。不过，currentTimeMillis() 也有 一些缺点。

currentTimeMillis() 的一个问题是，它虽然是以毫秒计数返回 时间，但是不能保证返回的计数的粒度或精度。在一些系统上，时间是真正的毫 秒计数，大约每一毫秒改变一次。在另一些系统上，时间可能每隔 10 或 20 毫秒才变一 次，因此每一次的精度都可能变化。

另一个局限是在方法定义中的基本时间单位。当 Java 平台第一次开始使用时，一毫秒 仍然是相当短的时间间隔（特别是对于解释语言）。今天，随着 CPU 时钟速度比第一次发布 Java 平台时快了近一百倍，一毫秒已经成了相对长的一段时间。

除了 currentTimeMillis() 的这些问题， 还有另一个使用任何类型的计时器方法监视程序执行都会有的问题。这个问题 是计时器方法本身 —— 可能要深入操作系统才能访问计时器 —— 这增加了一些开销， 如果计时器方法开销过大（或者方法调用过于频繁），那么就会严重扭曲计时测量。 为了明智地使用我们的性能跟踪方面，我需要至少大体知道计时器方法调用增加 了多少开销。

上面的说明来自IBM Develop的一篇文章，原文链接 ，English Version