Solaris マニアックス: Solaris 10の新機能とかの使い方を紹介するBlog

Ruby 1.9.0がSolaris上でコンパイルできたとのことなので、カッとなってJRubyとの性能比較をしてみました。

ベンチマークに使用したサーバは、X2200M2です。

使用したJRuby, Rubyのバージョンは以下の通りです。

X2200M2# jruby -v
ruby 1.8.5 (2007-12-28 rev 4842) [x86-jruby1.1b1]
X2200M2# /usr/local/bin/ruby -v
ruby 1.9.0 (2007-12-25 revision 14709) [i386-solaris2.10]

まずはサンマイクロお得意のフィボナッチ数列の計算

 （３列目の数字が実行に掛かった秒数です。）

 
JRuby 1.1b1

X2200M2# jruby bench_fib_recursive.rb
  1.003000   0.000000   1.003000 (  0.988000)
  0.570000   0.000000   0.570000 (  0.570000)
  0.561000   0.000000   0.561000 (  0.561000)
  0.561000   0.000000   0.561000 (  0.561000)
  0.562000   0.000000   0.562000 (  0.562000)
  0.561000   0.000000   0.561000 (  0.561000)
  0.560000   0.000000   0.560000 (  0.561000)
  0.561000   0.000000   0.561000 (  0.561000)

Ruby 1.9.0

X2200M2# /usr/local/bin/ruby bench_fib_recursive.rb
  0.360000   0.000000   0.360000 (  0.360941)
  0.360000   0.000000   0.360000 (  0.362891)
  0.370000   0.000000   0.370000 (  0.368229)
  0.370000   0.000000   0.370000 (  0.370920)
  0.370000   0.000000   0.370000 (  0.367976)
  0.370000   0.000000   0.370000 (  0.368987)
  0.370000   0.000000   0.370000 (  0.368454)
  0.360000   0.000000   0.360000 (  0.368539)

負けたorz

次に文字列操作です。

JRuby 1.1b1

X2200M2# jruby bench_string_ops.rb
Measure string array sort time
  7.108000   0.000000   7.108000 (  7.095000)
  5.730000   0.000000   5.730000 (  5.730000)
  5.784000   0.000000   5.784000 (  5.784000)
  5.726000   0.000000   5.726000 (  5.726000)
  5.728000   0.000000   5.728000 (  5.728000)
Measure hash put time
  0.358000   0.000000   0.358000 (  0.358000)
  0.219000   0.000000   0.219000 (  0.219000)
  0.233000   0.000000   0.233000 (  0.233000)
  0.224000   0.000000   0.224000 (  0.224000)
  0.223000   0.000000   0.223000 (  0.223000)
Measure hash get time (note: not same scale as put test)
  0.804000   0.000000   0.804000 (  0.804000)
  0.768000   0.000000   0.768000 (  0.768000)
  0.770000   0.000000   0.770000 (  0.770000)
  0.764000   0.000000   0.764000 (  0.764000)
  0.761000   0.000000   0.761000 (  0.761000)
Measure string == comparison time
  0.748000   0.000000   0.748000 (  0.748000)
  0.676000   0.000000   0.676000 (  0.676000)
  0.668000   0.000000   0.668000 (  0.668000)
  0.688000   0.000000   0.688000 (  0.687000)
  0.681000   0.000000   0.681000 (  0.681000)
Measure string == comparison time, different last pos
  0.868000   0.000000   0.868000 (  0.868000)
  0.818000   0.000000   0.818000 (  0.818000)
  0.824000   0.000000   0.824000 (  0.824000)
  0.835000   0.000000   0.835000 (  0.835000)
  0.833000   0.000000   0.833000 (  0.833000)
Measure string <=> comparison time
  0.971000   0.000000   0.971000 (  0.971000)
  0.918000   0.000000   0.918000 (  0.918000)
  0.916000   0.000000   0.916000 (  0.916000)
  0.957000   0.000000   0.957000 (  0.957000)
  0.910000   0.000000   0.910000 (  0.910000)
Measure 'string'.index(fixnum) time
  1.153000   0.000000   1.153000 (  1.153000)
  1.059000   0.000000   1.059000 (  1.059000)
  1.055000   0.000000   1.055000 (  1.056000)
  1.055000   0.000000   1.055000 (  1.055000)
  1.056000   0.000000   1.056000 (  1.057000)
Measure 'string'.index(str) time
  1.435000   0.000000   1.435000 (  1.435000)
  1.351000   0.000000   1.351000 (  1.351000)
  1.355000   0.000000   1.355000 (  1.355000)
  1.352000   0.000000   1.352000 (  1.352000)
  1.353000   0.000000   1.353000 (  1.353000)
Measure 'string'.rindex(fixnum) time
  0.831000   0.000000   0.831000 (  0.830000)
  0.755000   0.000000   0.755000 (  0.756000)
  0.752000   0.000000   0.752000 (  0.752000)
  0.755000   0.000000   0.755000 (  0.755000)
  0.756000   0.000000   0.756000 (  0.755000)
Measure 'string'.rindex(str) time
  1.617000   0.000000   1.617000 (  1.617000)
  1.570000   0.000000   1.570000 (  1.570000)
  1.571000   0.000000   1.571000 (  1.571000)
  1.567000   0.000000   1.567000 (  1.568000)
  1.572000   0.000000   1.572000 (  1.572000)

Ruby 1.9.0

X2200M2# /usr/local/bin/ruby bench_string_ops.rb
Measure string array sort time
  6.700000   0.020000   6.720000 (  6.710143)
  6.710000   0.000000   6.710000 (  6.714079)
  6.710000   0.000000   6.710000 (  6.709830)
  6.700000   0.000000   6.700000 (  6.698251)
  6.710000   0.000000   6.710000 (  6.705201)
Measure hash put time
  0.470000   0.010000   0.480000 (  0.479858)
  0.460000   0.000000   0.460000 (  0.460684)
  0.520000   0.000000   0.520000 (  0.518897)
  0.480000   0.000000   0.480000 (  0.473332)
  0.520000   0.000000   0.520000 (  0.523691)
Measure hash get time (note: not same scale as put test)
  1.190000   0.000000   1.190000 (  1.189463)
  1.270000   0.000000   1.270000 (  1.270908)
  1.230000   0.000000   1.230000 (  1.224017)
  1.260000   0.000000   1.260000 (  1.261356)
  1.270000   0.000000   1.270000 (  1.269975)
Measure string == comparison time
  1.540000   0.000000   1.540000 (  1.545910)
  1.550000   0.000000   1.550000 (  1.545590)
  1.540000   0.000000   1.540000 (  1.545325)
  1.560000   0.000000   1.560000 (  1.558849)
  1.550000   0.000000   1.550000 (  1.543557)
Measure string == comparison time, different last pos
  1.540000   0.000000   1.540000 (  1.539490)
  1.520000   0.000000   1.520000 (  1.526482)
  1.530000   0.000000   1.530000 (  1.525341)
  1.520000   0.010000   1.530000 (  1.525925)
  1.540000   0.000000   1.540000 (  1.531647)
Measure string <=> comparison time
  1.580000   0.000000   1.580000 (  1.582389)
  1.570000   0.000000   1.570000 (  1.576323)
  1.580000   0.000000   1.580000 (  1.575421)
  1.580000   0.000000   1.580000 (  1.576632)
  1.570000   0.000000   1.570000 (  1.575474)
Measure 'string'.index(fixnum) time
bench_string_ops.rb:219:in `index': type mismatch: Fixnum given (TypeError)
        from bench_string_ops.rb:219:in `block (4 levels) in bench_string_index_char'
        from bench_string_ops.rb:217:in `upto'
        from bench_string_ops.rb:217:in `block (3 levels) in bench_string_index_char'
        from bench_string_ops.rb:216:in `times'
        from bench_string_ops.rb:216:in `block (2 levels) in bench_string_index_char'
        from /usr/local/lib/ruby/1.9.0/benchmark.rb:293:in `measure'
        from bench_string_ops.rb:214:in `block in bench_string_index_char'
        from bench_string_ops.rb:213:in `times'
        from bench_string_ops.rb:213:in `bench_string_index_char'
        from bench_string_ops.rb:336:in `run'
        from bench_string_ops.rb:344:in `<main>'

あらら、途中でRuby 1.9.0は止まっちゃいました。

非互換に引っかかったのかもしれません。

実行できてる部分を見ると、JRubyの方がちょっと早いみたいですねｗ

ちなみに、JRubyはYARV互換もあるので、スクリプトが1.8系でも1.9系でも動きますよん。

先日、MySQL Users Conference Japan 2007 で行ったデモを公開します。
 

このデモでは、Ruby on Railsの動作をDTraceを使って追跡し、RubyのFunctionの呼び出し回数や実行時間、平均実行時間、CPU利用時間、CPU平均利用時間をリアルタイムでグラフィカルに確認することができます。

例えば、Ruby on Railsで作成されたWebアプリにアクセスがあったときに、どのソースコードのFunctionが何回呼び出され、実行に何秒掛かったなど、今までのデバックでは解析が難しかった情報を、簡単にリアルタイムで解析できます。

しかも、既存のソースコードに全く変更を加えず、オーバーヘッドもほとんど無くです！

先日、MySQL Users Conference Japan 2007で、[MySQL 超高速化 Know How」というセッションを行いました。

その際使用した資料です。

Solarisを使ってMySQLなどをチューニングする際の参考になれば幸いです。

MySQL 超高速化 Know How(OpenOffice)

MySQL 超高速化 Know How(PDF) 

後日、セッションの際にご紹介したDtraceのデモも公開したいと思います。

こちらに興味のある方、もうしばらくお時間ください。<(_ _)>

Web2.0では、大量に安価なサーバを使用して、水平分散しているシステムが多く見られます。

これは、かの有名なGoogleが採用しているアーキテクチャで、便宜上Googleモデルと呼ぶことにします。

このGoogleモデルは、システム立ち上げ時には、安価なサーバ数台で構成し、サービスが伸びてきたら拡張するというインフラの構築シナリオになっています。

そのため、サービス立ち上げ時には投資を最小化でき、経営的にはリスクの非常に低いモデルになっています。

特にベンチャー企業では、少ない資金でスタートでき、非常にメリットがあるように思えます。

 
しかしながら、サービスが順調に軌道に乗っていくとどうなるでしょう？

ユーザー数の増加にともない、サービスのレスポンスを維持するために、どんどんサーバを増設しなければなりません。

サービス立ち上げ時には数台だったサーバも、あっという間に100台近くに増えてしまいます。

こうなると、サーバを増やしても性能は上がりにくくなり、サーバの故障台数も増え、管理の手間ばかり増えてきます。

しかも、データセンターのラックはどんどん増え、ラック費用、電気代などのサービス維持費用が問題になってきます。

いまさらシステムの効率を改善するために、アプリの大きな変更などはできません。

それでもサービスのレスポンスを維持するために、サーバを増設しなければなりません。。。

実はこのモデル、サービスが伸びていくと体力（人、物、金）勝負になるという厳しいモデルなのです。

私が担当しているWeb2.0系のお客様達は、みなさんサーバの台数が増えすぎて困っています。

サーバの購入費用は十分安いけど、運用管理費用が逆に大きな負担になっています。

みなさんGoogleモデルのシステムをお持ちです。

ここで、Googleモデルのシステムに対して、私からの提案です。

「これからは、サーバの台数を減らすことに注力しませんか？」

そのためには、どんなことを考え、なにをすべきなのか。

まあ、サーバベンダーの言う事じゃ無いかもしれませんがｗ

２年ぐらい更新してなかったようですね。。。

前年度はT1プロセッサ搭載サーバの担当をしていて、Web2.0系企業にT1プロセッサやSolarisのプロモーションを行っていました。

本年度は、前年度の実績（？）を買われ、Web2.0系企業の担当になりました。

せっかくWeb2.0系企業の担当になったので、このBlogではWeb2.0系システムをSolarisに移行してバンバン言わせるノウハウを公開しちゃおうと思います。

Web2.0システムのボトルネック解析、チューニング、インフラによる性能向上のノウハウなどを中心に解説していこうと思います。