はじめに
連載4回目の今回は、前回に引き続いて実機を使った設定手順、パフォーマンスの測定を行っていきます。前回はルータとして動作させるためのネットワーク設定の方法とIPルーティングのスループットの測定を行い、最新のIAサーバにも迫る性能を確認することができました。今回はOpenBlockS 600をHTTPサーバとして使用した場合を想定して、LAMP(Linux,Apache,MySQL,PHP) 、Ruby on Railsの環境でのパフォーマンス測定を行います。
SSD/Linuxのパッケージ管理機能
OpenBlockSに標準搭載されているSSD/Linuxには、パッケージ管理のしくみとして、pkgsrc を採用しています。ぷらっとホームでは、pkgsrcに登録されているソフトウェアの中から需要の多いものを中心にバイナリパッケージを用意していますので、基本的なものであればコンパイル操作を行うことなくソフトウェアの導入が可能です。
バイナリパッケージのインストール
標準ではインターネットを通じてダウンロードし、インストールの実行をするようになっています。クローズドなネットワークでも、別途ダウンロードを行っておくことで利用することができますが、今回はインターネットに接続可能な状態であることを前提にしています。
実行は図1のように、pkg_addコマンドの引数に導入したいソフトウェアの名称を指定するだけです。例ではPHPのインストールを行っていますが、他のソフトウェアの場合も同様にインストール可能です。ソフトウェアはすべて/usr/pkg以下にインストールされ、各ソフトウェアの設定ファイルは/usr/pkg/etc以下にまとめられています。
図1 ソフトウェアの導入(例:PHPの場合)
# pkg_add php
===========================================================================
$NetBSD: MESSAGE,v 1.8 2007/05/05 21:45:12 adrianp Exp $
To process PHP scripts, you will need a PHP-enabled HTTP server. You may
either configure the HTTP server to use the PHP CGI binary located in
/usr/pkg/libexec/cgi-bin/php
or you may install a PHP module for your HTTP server, e.g. www/ap-php.
Note that php-openssl is no longer a separate package as of version
5.0.5nb1 because the main PHP5 package has it built-in now.
As of version 5.2.1nb3 PEAR is no longer installed by default with the
php package. In order to use PEAR packages with PHP you will need to
install the lang/pear package.
===========================================================================
デーモンの自動実行の設定
Apache、MySQLなどをデーモンとして起動時に自動実行させたい場合は、ネットワーク設定と同じく/etc/rc.confファイルに追記します。設定例はリスト1です。ご覧のとおり、自動起動させたいソフトウェアを変数名にして、値にYESを設定しています。この変数名は、ソフトウェアインストール後に/usr/pkg/etc/rc.dへ追加される起動スクリプト(図2)のファイル名と一致している必要があります。
リスト1 自動起動の設定(/etc/rc.conf)
apache=“YES”
mysqld=“YES”
図2 起動スクリプトの例
# ls /usr/pkg/etc/rc.d/
apache mysqld
LAMPの環境構築
ソフトウェアパッケージをpkg_addコマンドで導入を行った後、動作に必要な最低限の設定を行っていきます。pacheはリスト2、PHPはリスト3を参照してください。動作させるWebアプリケーションには、CMS(コンテンツマネジメントシステム)のMODx を使用しています。MODxのインストール/設定は、開発元のWebページを参照してください。
リスト2 Apacheの設定(/usr/pkg/etc/httpd/httpd.conf)
……(省略)……
# DirectoryIndex: sets the file that Apache will serve if a directory
# is requested.
#
DirectoryIndex index.html index.php
……(省略)……
# 最終行に追記
LoadModule php5_module lib/httpd/mod_php5.so
AddHandler application/x-httpd-php .php
リスト3 PHPの設定(/usr/pkg/etc/php.ini)
……(省略)……
;;;;;;;;;;;;;;;;;;;;;;
; Dynamic Extensions ;
;;;;;;;;;;;;;;;;;;;;;;
extension=mysql.so
……(省略)……
Ruby on Railsの環境構築
Ruby本体はバイナリパッケージで導入し、Ruby用のパッケージ管理ツールRubyGemsとRailsはソースからインストールしています。導入の手順はリスト4を参照してください。動作させるアプリケーションには、LAMPの例と同じくCMSのRadiant を使用しています。Radiantのインストール/設定は、開発元のWebページ を参照してください。
リスト4 Ruby on Railsの環境構築
# gem18 install --no-rdoc --no-ri mysql -- --with-opt-lib=/usr/pkg/lib/mysql --with-optinclude=/
usr/pkg/include/mysql
Building native extensions. This could take a while...
Successfully installed mysql-2.7
1 gem installed
# gem18 install --no-rdoc --no-ri radiant
Building native extensions. This could take a while...
Successfully installed rake-0.8.7
Successfully installed RedCloth-4.2.2
Successfully installed radiant-0.8.0
3 gems installed
# gem18 install --no-rdoc --no-ri rack
Successfully installed rack-1.0.0
1 gem installed
# gem18 install --no-rdoc --no-ri thin -- --with-opt-dir=/usr/pkg
Building native extensions. This could take a while...
Successfully installed thin-1.2.2
1 gem installed
パフォーマンスの測定
動作環境の設定が済んだところで、静的なHTMLファイル、LAMP、Ruby on Railsでの毎秒に処理したリクエスト数を、Apacheに付属のベンチマークソフト Apache Benchを使用して測定してみました(図3) 。比較対象としてIAサーバでの測定も行っています(表1) 。
結果はご覧のとおり、前回のネットワーク性能の比較のときのようにはパフォーマンスが出ず、IAサーバに大きく水をあけられる結果となりました。しかし、数字的には大きな差が出ていますが、静的コンテンツの配信用途には、十分に実用的な性能と言えるでしょう。1秒あたり238リクエスト、1分あたり14,280リクエストを処理できており、1ページのファイル数が50あったと想定して、毎分およそ286クライアントからの接続を処理可能です。
またLAMPやRailsに関しては、ベンチマーク結果ではRailsが勝っていますが、体感的はLAMPのほうが全体的にスムーズに使える印象です。Railsの場合は、初回アクセスは待たされることもありますが、キャッシュ機構が働いている操作は非常にスムーズです。アプリケーションの場合は作り込み次第でベンチマーク結果が変わってきますので、個人やオフィス内の小規模なサーバであれば十分に活用頂けるかと思います。
以上のとおり、今回のパフォーマンス測定では、アプリケーションサーバとしての性能面では、IAサーバには敵わないことを確認できたのと同時に、使い方次第では十分な性能が出ることも、よくお伝えできたかと思います(なお今回の評価データは、開発段階のOS環境下での値であり、出荷時点での結果とは異なる場合があります) 。
図3 スループットの測定
表1 測定結果(単位:リクエスト/秒)
OpenBlockS 600 IAサーバ
静的HTML 238.61 3292.71
LAMP(MODx) 4.35 22.80
Rails(Radiant w/thin) 7.08 288.044
Column「OpenBlockS 600の秘密」
OpenBlockSシリーズは初期のモデルのころより、壊れにくさを追求し、ファンレス・駆動部品ゼロなどを基本的なコンセプトとして開発されてきました。
最新モデルのOpenBlockS 600では、そのコンセプトをさらに徹底しています。
前のバージョン、OpenBlockS 266では図A に示すとおり、①メインボード、②コンパクトフラッシュ用の変換ボード、③2枚のボードを接続するジョイントボード、の計3枚で構成されていました。
図A OpenBlockS 266の内部構成
新製品のOpenBlockS 600では、従来のような複数枚の基板を組み合わせて使用するのではなく、すべての機能を1枚の基板上に収めることで、コネクタの接点不良の可能性も未然に防いでいます(図B ) 。
また、壊れにくさへの追求は、これだけにとどまりません。OpenBlockSシリーズは、数年間に渡って使い続けられることが多く、長期間の使用では不安材料になってしまうケミカルコンデンサは一切使用せず、全て固形コンデンサを採用/搭載しています。
他にもケースカバーには、Ethernetやコンソールなどの必要最小限のポート以外に開口部を設けていないことも重要なポイントです。小さく壊れにくいため、床下や配電盤の中など、あまり環境が良いとは言えない場所で使われることも多くありますが、ケース内がきれいに保たれているため、ホコリの付着やそれに伴うサビの発生なども抑えられています。
小型でLinuxの動作するハードウェアは多数ありますが、OpenBlockSは壊れにくさという観点から小型パソコンでは担うことができない役割を持ったサーバとして、さまざまな用途・場所で利用されています。
図B OpenBlockS 600は1枚のボードに機能を集約