Monthly Archives: 7月 2013

追記＠2013年10月17日

rbenvのインストールの際に、シンボリックリンクがおかしくなっていることがあります。
Macでrbenvをgit-cloneしたときに、シンボリックリンクがおかしくなっていた件

そのときはこんな処理をしてみるといいと思います↓

$ cd ~/.rbenv/bin

# 削除
$ rm ./rbenv
 
# シンボリックリンクを貼る
$ ln -s ../libexec/rbenv ./rbenv

要約(長い記事なので):
—–
– Ubuntuでsinatraを動かすことが出来ました。
– Nginxで複数のsinatraを集約することが出来ました。
– パフォーマンスも計測しました。
– 最近のCPUであれば1coreあたり2000req/sec程度出るようです。
—–

思うところあってRubyのSinatraをインストールしてベンチマークを取りたくなりました。自然とRESTになるのがいいですね。とは言えたとえばGoogle検索のURLはぜんぜんRESTじゃないので、あまりRESTにこだわる価値はないのかもと思うところもありますが。

環境は、Ubuntu 12系です。おそらくDebian系なら以下の方法で行けると思います。

導入

# 必要なパッケージをインストール
$ aptitude install zlib1g-dev openssl libssl-dev libreadline-dev make gcc g++ git build-essential

# ホームに戻る
$ cd
$ git clone git://github.com/sstephenson/rbenv.git .rbenv
$ echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bashrc
$ echo 'eval "$(rbenv init -)"' >> ~/.bashrc
$ exec $SHELL
$ mkdir -p ~/.rbenv/plugins
$ cd ~/.rbenv/plugins
$ git clone git://github.com/sstephenson/ruby-build.git

# ↓2013年7月16日時点での最新版。少し時間が掛かります($rbenv install --list として手に入るものを探しても良い)
$ rbenv install 1.9.3-p448
$ rbenv rehash
$ rbenv global 1.9.3-p448
$ cd 
$ echo 'install: --no-ri --no-rdoc' >> .gemrc
$ echo 'update: --no-ri --no-rdoc' >> .gemrc
$ gem install thin
$ gem install sinatra

# thinやsinatraを使うのに、rbenv rehashが必要です
$ rbenv rehash

# Exampleを作るために、ディレクトリを作ります
$ mkdir app
$ cd app/

# app.rb, config.ru, thin.config.ip.ymlの中身は下に別記
$ vi app.rb
$ vi config.ru
$ vi thin.config.ip.yml
$ echo 'thin start -C thin.config.ip.yml' >> run.sh
$ echo 'thin stop -C thin.config.ip.yml' >> stop.sh

# 起動
$ sh run.sh

# リクエストを送信して確認
$ curl -i http://localhost:4040/hello/bar
-----
HTTP/1.1 200 OK
Content-Type: text/html;charset=utf-8
Content-Length: 10
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Connection: keep-alive
Server: thin 1.5.1 codename Straight Razor

Hello bar!
-----

# ポートとプロセスを確認
$ sudo netstat -natp
-----
~中略~
tcp        0      0 0.0.0.0:4040            0.0.0.0:*               LISTEN      933/thin server (0.
~中略~
-----

# 終了
$ sh stop.sh

app.rb

#coding: utf-8
require 'sinatra/base'
class MyApp < Sinatra::Base
  get '/' do
    "Hello World! I am sinatra!"
  end
  get '/hello/:name' do
  # matches "GET /hello/foo" and "GET /hello/bar"
  # params[:name] is 'foo' or 'bar'
  "Hello #{params[:name]}!"
  end
end

config.ru

#coding: utf-8
require File.dirname( __FILE__ ) + '/app.rb'
run MyApp

thin.config.ip.yml

timeout: 30
log: log/thin.log
#environment: production
environment: development
servers: 1
daemonize: false
rackup: config.ru
port: 4040

次はパフォーマンスを見てみます。thinを↑の設定で、NECのサーバーに入れて、富士通サーバーからApache Benchしてみました。

NECサーバーのスペック(いわゆる鼻毛鯖)
– Celeron G540
– DRAM 8GB * 2
– 500GBHDD
– Ubuntu 12.04 Server AMD64
– Linux Kernel 3.2.0-45-generic #70-Ubuntu SMP

ネットワークトポロジー
NECサーバー <= GbE => GbEスイッチングハブ <= GbE => 富士通サーバー

# NECサーバーに対して、富士通サーバーからApache Benchしています
$ ab -n 100000 -c 100 http://192.168.1.3:4040/hello/performance
-----
~~~
Server Software:        thin
Server Hostname:        192.168.1.3
Server Port:            4040

Document Path:          /hello/performance
Document Length:        18 bytes

Concurrency Level:      100
Time taken for tests:   47.750 seconds
Complete requests:      100000
Failed requests:        0
Write errors:           0
Total transferred:      25400000 bytes
HTML transferred:       1800000 bytes
Requests per second:    2094.22 [#/sec] (mean)
Time per request:       47.750 [ms] (mean)
Time per request:       0.478 [ms] (mean, across all concurrent requests)
Transfer rate:          519.47 [Kbytes/sec] received
~~~
-----

評価:
2094 req/sec程度でした。1プロセスでこの速度というのは、そこそこ高速と言えるのではないでしょうか。このアクセスを捌いているときのNECサーバーの様子を以下に示します。

$ dstat
You did not select any stats, using -cdngy by default.
----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai hiq siq| read  writ| recv  send|  in   out | int   csw 
  1   0  99   0   0   0|  16k   51k|   0     0 |   0     0 | 149    98 
 46   2  50   0   0   2|   0     0 | 924k 1233k|   0     0 |4514   254 
 42   3  50   0   0   5|   0     0 | 924k 1232k|   0     0 |4490   232 
 46   3  50   0   0   1|   0     0 | 927k 1237k|   0     0 |4528   248 
 44   1  50   0   0   5|   0     0 | 925k 1232k|   0     0 |4496   235

こんな感じでした。2コアのマシンですので、1コアはほぼ完全に使い切っているということになります。また、CPU使用率のsysのところでは3となっていますが、これはTCP/IPの処理ではないでしょうか。
ちなみにApache + PHPでの”Hello, world”では、8295 req/secでした。

次に、thinプロセスを増やし、nginxに集約させてみます。今回はthinプロセスをUnix Domain Socketで複数動かし、Nginxをリバースプロキシにします。

先ほど作ったappをコピーしてapp2を作りそこに移動して、thin.config.ip.ymlを書き換えます。

$ cd
$ cp -R app/ app2/
$ cd app2
$ mkdir sock
$ vi thin.config.ip.yml

thin.config.ip.yml

environment: development
timeout: 30
log: log/sinatra.log
pid: pid/sinatra.pid
max_conns: 2048
max_persistent_conns: 1024
require: []
wait: 30
daemonize: true
socket: sock/sinatra.sock
servers: 2

ひとまず「servers: 2」、つまりthinプロセスを2個作ります。

次にNginxの設定をします。

# Nginxをインストールします
$ sudo aptitude install nginx

# 設定ファイルのバックアップを取っておきます。
$ sudo cp /etc/nginx/sites-available/default /etc/nginx/sites-available/default.bk

# 設定を書き換えます。下に別記しています。
$ sudo vi /etc/nginx/sites-available/default

# 走らせます
$ sudo /etc/init.d/nginx start

/etc/nginx/sites-available/default の中身(注意！/home/kawa/~略~となっていますが、ユーザー名は人のよって異なるので、自分のユーザー名に書き換えてください)

server{
  listen 8080;
  #server_name example.com;
  proxy_set_header  X-Real-IP       $remote_addr;
  proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header  Host            $http_host;
  proxy_redirect    off;
  proxy_max_temp_file_size          0;
  location / {
    proxy_pass http://sinatra;
  }
}
upstream sinatra {
  server unix:/home/kawa/app2/sock/sinatra.0.sock;
  server unix:/home/kawa/app2/sock/sinatra.1.sock;
}

Apache Benchの前に、きちんとNginxとthinの設定がうまく行っているか確認します。

$ curl -i http://localhost:8080/
HTTP/1.1 200 OK
Server: nginx/1.1.19
Date: Tue, 16 Jul 2013 02:13:25 GMT
Content-Type: text/html;charset=utf-8
Content-Length: 26
Connection: keep-alive
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN

Hello World! I am sinatra!

↑きちんとNginxを経由していますね。さて、Apache Benchしてみます。

# NECサーバーに対して、富士通サーバーからApache Benchしています
$ ab -n 100000 -c 100 http://192.168.1.3:4040/hello/performance
-----
~~~
Server Software:        nginx/1.1.19
Server Hostname:        192.168.1.3
Server Port:            8080

Document Path:          /hello/performance
Document Length:        18 bytes

Concurrency Level:      100
Time taken for tests:   33.129 seconds
Complete requests:      100000
Failed requests:        0
Write errors:           0
Total transferred:      26900000 bytes
HTML transferred:       1800000 bytes
Requests per second:    3018.54 [#/sec] (mean)
Time per request:       33.129 [ms] (mean)
Time per request:       0.331 [ms] (mean, across all concurrent requests)
Transfer rate:          792.96 [Kbytes/sec] received
~~~
-----

評価:
前回は2000 req/sec程度でしたが、1.5倍の速度になりました。素直に2倍にはなってくれませんね。Nginxを経由しますので遅くなるのでしょうか。また、dstatを見てみます。

$ dstat
You did not select any stats, using -cdngy by default.
----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai hiq siq| read  writ| recv  send|  in   out | int   csw 
 85  10   0   0   0   5|   0     0 |1370k 1872k|   0     0 |  11k   15k
 84  12   0   0   0   5|   0     0 |1361k 1859k|   0     0 |  12k   14k
 81  12   0   0   0   6|   0    12k|1363k 1862k|   0     0 |  11k   15k
 86  10   0   0   0   4|   0     0 |1369k 1870k|   0     0 |  11k   14k
 82  12   0   0   0   6|   0     0 |1383k 1890k|   0     0 |  11k   13k

これを見るに、CPUを完全に使い切っています。ということは、プロセスを増やしても性能の向上は期待できなさそうです。

次に、4つのthinプロセスにしてみます。おそらく伸びませんが。。。
thin.config.ip.ymlの「servers」を4に、/etc/nginx/sites-available/default の「upstream sinatra」のところに追加、で出来ます。sinatraとnginxのrestartを忘れずにしましょう。

# NECサーバーに対して、富士通サーバーからApache Benchしています
$ ab -n 100000 -c 100 http://192.168.1.3:4040/hello/performance
-----
~~~
Server Software:        nginx/1.1.19
Server Hostname:        192.168.1.3
Server Port:            8080

Document Path:          /hello/performance
Document Length:        18 bytes

Concurrency Level:      100
Time taken for tests:   37.284 seconds
Complete requests:      100000
Failed requests:        0
Write errors:           0
Total transferred:      26900000 bytes
HTML transferred:       1800000 bytes
Requests per second:    2682.09 [#/sec] (mean)
Time per request:       37.284 [ms] (mean)
Time per request:       0.373 [ms] (mean, across all concurrent requests)
Transfer rate:          704.57 [Kbytes/sec] received
~~~
-----

評価:
2個のプロセスのときよりも若干遅くなってしまいました。予想通り、2個のthinプロセスでこのマシンは限界を迎えるので、4個のthinプロセスを立てても全くの無駄でした。

蛇足:
富士通サーバー(Opteron 3280)をサーバーにしてやってみました。
– thinプロセス 8個
です。

Server Software:        nginx/1.1.19
Server Hostname:        192.168.1.2
Server Port:            8080

Document Path:          /hello/performance
Document Length:        18 bytes

Concurrency Level:      100
Time taken for tests:   11.275 seconds
Complete requests:      100000
Failed requests:        0
Write errors:           0
Total transferred:      26900000 bytes
HTML transferred:       1800000 bytes
Requests per second:    8869.56 [#/sec] (mean)
Time per request:       11.275 [ms] (mean)
Time per request:       0.113 [ms] (mean, across all concurrent requests)
Transfer rate:          2329.99 [Kbytes/sec] received

1万req/sec近く出ています。さすが8core、、、と言いたいところですが、注目するべき点は、
>Time per request: 11.275 [ms] (mean)
でしょう。先ほどのNECサーバー(Celeron G540)のときは、
>Time per request: 37.284 [ms] (mean)
でした。うーん、どういうことでしょう。今まで様々なベンチマークを取って来ましたが、常にCeleron G540 > Opteronでした。何かおかしい気がします。。。現在調査中です。。。G540サーバーはもっと良い成績が出ると思います。

Nginxを使わずにsinatraを単独で(port:4040)動かしてみると次のようになりました。
G540(鯖): Time per request: 47.531 [ms] (mean)
Opteron(鯖): Time per request: 36.184 [ms] (mean)

うーん、そこまで差があるわけではないですね。不思議です。Opteronの方は綺麗に集約されるけれども、G540の方は集約されないということみたいですが、きっと何かがおかしいはず。。。