こんにちは、おがしょ〜です。
タイトルどおりですが、今回は「やってみた」系です。

内容は「ESXiをUSBメモリブート > ESXi 3.5 のインストール > Sun xVM VirtualBox で使用していたVMをインポート > 実行」って感じです。バージョンは v4 と v3.5 の2種類あるようですが、なんとなく x64=v4、x86=v3.5 みたいな感じがしたので今回は v3.5update4 をチョイスしました。まったく使用されないまま足下に転がってるDELLが不憫でESXiを入れてみました。
　（ほんとは XEN にしようとしてましたが、、面倒くさいので、、、、
興味の無い人にはまったく興味ない分野ですね、すいません(・∀・)


以下さくっとVMware ESXiの説明。

1. 仮想OSを実行するための仮想機械（バーチャルマシン）。
2. いわゆるType1ハイパーバイザと呼ばれる（VirtualBox とか VMware Server とかはType2）。
3. 実行するマシンを選ぶが、その分ホストOSが必要ない。→余計なボトルネックが少ない
4. 基本Intelのチップセットを所望される模様→特に NIC と StorageAdapter
5. 無償である。（※商用利用の場合とかは調べてません）

一番はじめ、ESXiがよくわからなかった時、知見のある方から「まずUSBメモリからブートしてみればいいよ」との助言を頂いたのでさっそくググってみる。（T様ありがとうございます！！）するとだいたい・・・

1. インストールCDイメージをダウンロードする。ちなみに、結構面倒な登録フォームでユーザー登録（無料）をする必要があります。
2. ダウンロードしたイメージをマウントして中身の「install.tgz」を適当な場所に解凍する。
3. さらにその中の「usr/lib/vmware/installer/VMware-VMvisor-big-3.5.0_Update_4-153875.i386.dd.bz2」を解凍する。    $ bzip2 -d usr/lib/vmware/installer/VMware-VMvisor-big-3.5.0_Update_4-153875.i386.dd.bz2
4. 出てきた「VMware-VMvisor-big-3.5.0_Update_4-153875.i386.dd」を dd でUSBメモリにコピー。※WIN!!な人はWinDDとか使うがいいです。    $ dd if=VMware-VMvisor-big-3.5.0_Update_2-153875.i386.dd of=/dev/sdb bs=1024    ※dd の引数of=は必ず実行中の環境に合わせてください！！

こんな感じの手順で起動用のUSBメモリが作れました。実際にUSBメモリを挿してブートする前に、BIOSの起動順序のところでUSBメモリを上位に設定しておきます。


HDDのインターフェースがIDEなウチのDimension君なんですが、USBブートしてみるとちゃんと認識されてました！！もちろんNICも問題なし！！SATAのみのサポートっぽいことが随所に書いてある ESXi だったのでかなりビクビクしてましたが、要らぬ心配だったみたいです。起動後にモニタに表示されるURLを叩いて、表示されたページから VMware Infrastructure Client をダウンロードします。「〜.exe」ってなってるのでWindows用ですか。ですよね。MacOSXなのに・・・。


で、VMware Infrastructure Client で一通り画面をみつつ、やっぱりHDDにインストールすることにしました。（USBメモリ他にも使うし。。）
手順は↑で使ったインストールCDイメージをCDに焼いて、CDブートして、普通にインストールするだけ。・・・かと思ったら途中で

Installation operation Failed!The installation operation has encountered a fatal error:Unable to find a supported device to write the VMware ESX Server 3i 3.5.0 image to.

みたいなエラーでインストール出来ない！！ググってみました。まさにドンぴしゃな素敵ページ発見！！
trial and error様 <http://techno-st.net/2009/01/23/vmware-esxi-ide-hdd.html>


なるほど、インストール時の判定でIDEコントローラだと弾かれるのね。。
Dimension8300はまったく同じ手順でIDE HDDを無事認識できました！！インストールも特に問題なく終了し、後はUSBメモリブートの時と同じでした。


＝＝＝ タバコ休憩 ( ´ー｀)y-~~ ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝


そして、最後に既存の VirtualBox2.2 のVMをインポートします。
手順は

1. VirtualBoxで仮想アプライアンスのエクスポート。「Write legacy OVF 0.9」にチェックを付けること。
2. VMware Infrastructure Clientで出力したOVFファイルをインポート。

以上でOKなハズなんですが、インポート時にいくつかエラーが出たので、手でOVFファイルを修正する必要があります。エラーメッセージをメモってなかったので適当な表現で( TДT)ｺﾞﾒﾝﾖｰ

• 「Envelope」エレメントがなんとかかんとか、エラー
  
  • VirtualBoxの出力では<Envelope>・・・</Envelope>となってますが、ESXi的には<ovf:Envelope>・・・</ovf:Envelope>にして欲しいようです。
• 「ovf:version」属性がほげほげ、エラー
  • <ovf:Envelope ovf:version=”0.9″ …> と先頭にこの属性があるのが気に入らないようです。<ovf:Envelope   ….  ovf:version=”0.9″> のように最後にしてあげるとエラーが取れました。
• 「vssd:VirtualSystemType」がエラー
• VirtualBoxでは「vmx-6」になってますが、ESXi3.5では「vmx-04」にするといいみたいです。ちなみにESXi4.0では「vmx-06」とかで、「xen3」とかもあるみたい？
• 「disk1」のデバイスがおかしいっぽい？エラー
  • VirtualBoxでIDEコントローラを使っていた場合に出るみたいで、ESXiではSCSIコントローラに置き換えてあげる必要があります。Itemエレメント「IDE Controller」を次の様に変更します。
  1. rasd:Description => “SCSI Controller”
  2. rasd:ResourceType => “6″
  3. rasd:ResourceSubType => “lsilogic”

今回インポート時に出たエラーは以上です。

ここまでの修正を施したOVFファイルを再度インポートします。エラーが出なければHDイメージファイル（vmdk）のアップロードが始まります。これがまた遅い・・・。2ファイル合計1.5GBほどで1時間くらいかかったと思います。


ようやくインポートが終わったのでVMware Infrastructure ClientからVMを実行。VirtualMachinesタブを開いて、対象のVMを右クリックし、「Open Console」を選択するとコンソール画面が開きます。まだVMを起動してなければコンソール画面の右三角ボタンをクリックでインスタンスの起動が行えます。あと今更レビューなんですが、このクライアントソフト、UI言語は英語なんですが直感的で非常に使いやすいです。


はじめてESXiで動かした感想、これは素晴らしい！！
なんか、きっちりマシンリソースを使えてる感が気持ちいいです。
Dimension8300 の CPU は Pentium4 の2.8GHzなんですが、はっきりいってう●■みたいな性能だと思ってました。ごめんなさいごめんなさい。。
これからも色々実験台として活躍していただきます(´∀｀)


なんだか無駄に長い割に役に立ちそうにないエントリですが、とりあえず今日はここまで。

こんにちは、おがしょ〜です。
前回の更新から1ヶ月以上が経過してしまいました。。

さて前回、

もっと細かく調べてみたところ、CakePHPのコア部分でいくつか微妙な箇所がありました。

1. モデルをたくさん使っているコントローラが遅い
2. セッションのストア先にmemcachedを指定すると遅い
3. ImageMagick（convert）の変換処理が遅い

と、3つの問題点を挙げていましたので、今回はそれについて適当なことを書いてみます。


まず1.の「モデルをたくさん使っているコントローラが遅い」について。
CakePHP1.2の便利な点として、割と使いやすいO/Rマッパーの存在があります。ざっくり言えばRDBをテーブル単位で構造化されたオブジェクト（モデルクラスとか）として扱える、ってそんな感じの機能です。さらにCakePHPでは、モデルとモデルの関連性を定義しておくことにより、O/Rマッパーが勝手に関連するものも取ってきてくれます。SQL的に言えばJOINするような感じで、これが超便利。


しかし、あまりに深い関連性を持たせるとなんでもかんでも取ってこられるので大変なことになります。
例えば、

ModelA =|1:n|= ModelB
ModelB =|1:n|= ModelC
ModelB =|1:n|= ModelD

と4つのモデルがこのような関係であった場合、ModelAのみ必要な場合に取得しようとすると、SQL的に “ModelA JOIN ModelB JOIN ModelC …” となってしまうとこは容易に想像つきますし、これは他の方も行っているexpectsメソッドを実装すれば割と簡単に解決できます。


でも問題はSQLクエリと結果の分量じゃなくて、CakePHPによって生成されるモデルインスタンス（と初期化時間）が問題でした。具体的には上記モデル構成の場合、リクエストのたびにModelA〜ModelDまでのインスタンスが必ず生成されます。expectsメソッドを実装したとしても、このインスタンス生成はコントローラの初期化時に行われるので全く効果がありません。


この辺りのCakePHPの動作をざっくりと･･･

1. コントローラの初期化
2. 使用するモデル定義を見る
3. モデルインスタンスを作成
4. 3.で作ったモデル内で、関連しているモデルインスタンスを作成
5. 3〜4を関連するモデルすべてで行う。

という感じになっています。
4.の動作がとっても間抜けな感じで、作り手のモデル定義によってはシステム全体のモデルのインスタンスを生成することになってしまいます。


この問題の解決策としては、

1. コントローラにモデルを登録せずに、メソッド内で必要なモデルのみを動的にアタッチする。（できるかどうか不明）
2. モデルのインスタンス生成を実際に必要なときにのみ行う。
   

の2択で考えてましたが、
当時のプロジェクトの進行度的に、かなりの修正作業の入る選択肢1.は不可能でした。
で、２．を選びました。思いつきのキーポイントはisset()やget()など、PHPのマジックメソッド。



要は関連するモデルの関連性のみを覚えておいて、実際にアプリがそのモデルを使おうとした時に、まだ無ければ初めてインスタンスを生成しよう、ってことです。適用前はコントローラの初期化時にかなりの数のインスタンスが生成されてましたが、適用後はメソッドごと必要な分のインスタンスのみが生成されているようです。


実際のコードについては以前CakePHP.jpのフォーラムに投げておいたのでそっちを参照してください。
（まったく反応がないのでちょっと寂しかったり ｡･ﾟ･(ﾉД`)･ﾟ･｡

ちなみに上記フォーラムに上げたコードにはその後に見つかった致命的なバグが残ってますが、お暇な方は試してみてください。

・・・とここまでを読み返してみて、やっぱり自分には文才が無いことを再確認しました。
長くなったので今日はこの辺で。

こんにちは、おがしょ〜です。

現在進行中のプロジェクトでCakePHPなるフレームワークを使っているんですが、これが機能満載で思いのほか重い。使用しているバージョンは 1.2RC3 です。「CakePHP パフォーマンス」とかでググってみると1.1に比べてだいぶ遅いというベンチマーク結果などが出てきました。やっぱり。。


とはいえ開発も終盤でフレームワークの変更はしたくないですし、メインの開発陣とは別にチューニング箇所について調査することにしました。まずシステム構成ですが、

• Linux（なんだっけ？）
• Apache2
• mysql5
• mod_php5

まんまLAMPですね。
あとはアプリ側キャッシュにmemcachedを使ってたり、画像配信にSquidを前に立てたりします。


で、PHP＆CakePHP側の主要な構成ですが、

• コードキャッシュ＆ローカルキャッシュにはAPCをチョイス。
• CakeのCacheエンジンはAPCとMemcacheを用途に応じて切り替え。
• Memcachedは複数サーバから同じデータを参照する必要のあるものにのみ使用する。それ以外のどうでもいいキャッシュはAPCに格納する。パフォーマンスはたぶんローカルmemcachedと同じようなものかと。

・・・な感じでしょうか。


まず、Apacheについてくる ab（ApacheBench） コマンドで実際のページのパフォーマンスを計測していきます。

>  $ ab http://example.jp/
コマンド終了時に表示された内容の「Requests per second: x.xx [#/sec]」の部分でだいたいの性能をみます。秒間n回リクエストを捌きました的な意味合いだと思います。


どんな数字が出れば速いのか？の基準については私もよくわかりません；；ただ体感的に考えて、1#/sec 程度だとブラウザの表示に最低1秒以上かかってることになるのであまりよろしくないですよね。この辺りの判断は人によります、たぶん・・・。


で、abで計測した結果をみて思ったことは、「なんか全体的に同じように遅い」でした。商品DBなんかの検索機能のあるページとかが飛び抜けて遅いだけなら複雑なSQLクエリとかが原因と考えられたりしますが、どうもそうではない様子。もっと細かく調べてみたところ、CakePHPのコア部分でいくつか微妙な箇所がありました。

1. モデルをたくさん使っているコントローラが遅い
2. セッションのストア先にmemcachedを指定すると遅い
3. ImageMagick（convert）の変換処理が遅い

3はCakePHP関係ないですね；結論からいうと上記3つが主なボトルネックでして、解決することでかなりのパフォーマンスアップが図れました！が、長くなりそうなので解決編は次回以降のエントリに分けます･･･。