OpenBlocks600の記事で紹介しましたブログビューアーですが、その後、バグ修正やRSS関係の対応をしてから1週間経ち、apacheのエラーログにもエラーが出ていないので、そろそろリリースしようかなと思いソースを眺めていたのですが、あまり教示的なソースでなく『公開すべきか、せざるべきか・・・』と悩んでおったのですが、こういうときは他人はどうしているのかと、最近のWEBアプリの動向でも探ろうかとネットを検索しましたところ、面白い記事を見つけました。
http://satoshi.blogs.com/life/2009/10/rails_mvc.html Ruby on Railsの「えせMVC」の弊害
http://satoshi.blogs.com/life/2009/10/ormappingmvc.html O/Rマッピング技術の進化が皮肉にも助長している「えせMVC症候群」
ブログ主（Satoshi Nakajimaさん）の主張ですが、要するにモデルとコントローラの役割はきちんと分けようねということで、『ビジネスロジックをコントローラに書くのはNG』とのことのようです。
ちなみに私ですが、ちょい書きのアプリだとまぁコントローラでビジネスロジックどころか、SQLを書いたりします。またブログビューアーの構造も思いっきりMVCモデルから逸脱しているので・・・という訳でブログビューアーを書き直そうかなとか思ったのですが、もう少し調べてみようということで、以下、Rubyの作者のまつもとさんの記事を見つけました。
http://itpro.nikkeibp.co.jp/article/COLUMN/20080610/307218/ まつもと直伝 プログラミングのオキテ 第20回 MVCとRuby on Rails
この記事の
7ページ目の表2にRailsのMVCということで従来のMVCとの比較がありますが、その表から2パラグラフ目の説明を引用しますと
一方，HTTPの性質によってUI部分の複雑さはWebブラウザに任せてしまっているWebアプリケーションでは，相対的にUI層が薄くなります。コントローラ相当はほぼ汎用品で十分ですし，モデルとビューのインタラクションも不要です。ですから，モデルをデータベース層とビジネス・ロジック層に分割して，下層をモデル，上層をコントローラと呼ぶようにしたのでしょう。
ということで、まつもとさんの説によるとビジネス・ロジック層はコントローラに記述することになるようです。
かの有名なRubyの作者のまつもとさんが、このように言っておられるのでこの勝負は『Railsでは、ビジネス・ロジック層はコントローラに記述する』で軍配が上がりそうですが、実は先のブログ主さん（Satoshi Nakajimaさん）も知る日とぞ知る方で、過去にマイクロソフト社に勤務されておりWindows95の開発では、Windows3.1との互換性を保つために尽力されたらしく、そのあたりの話は
こちらで参照できます。また先の主張は、実際に
Ruby on Railsを使ったプロジェクト通して行き着いたようでしてそれなりに説得力があります。
このように著名なエンジニアの見解が異なる場合、どのように解釈すればよいのか悩ましいところですが、実行速度についてとか明確に白黒つく場合のように客観的に測定できる事実が無い場合、
『どちらでも良い』
というのが私の経験から来る見解になります。
この手の議論はエンジニアを引き付けるものがあり、熱くなったりするのですが、議論してもみのりは少なかったりします。
私も過去にこの手の議論に巻き込まれたことがあるのですが、特に個々のエンジニアが持つバックグランドが異なる場合、あまり前向きな議論にならなかったです。
今はインターネットがあるので様々なエンジニアの見解を比較することができるので、このように『他の人はどう考えているか？』というのをわざわざ議論しなくても解るので改めていい時代になったと思います。
というわけで、まぁブログビューアーは作り直さずに公開したいと思います。
以前に、ADPを
OpenBlocks600Dに対応させた話を書きましたが、予告（？）どおり
ADP 0.61のリリースを行います。ブログビューワーの方は後ほどということで・・・必要な方はコメント欄にほしいとリクエストください（気持ち急ぎます）。
OpenBlockS600Dのバイナリ版を実行させる場合は以下のパッケージがインストールされている必要があります。
- libboost-regex1.35.0
- openssl
- unixodbc
場合によっては（ソースからコンパイルされる方は）さらに以下のパッケージが必要です。
- libboost1.35-dev
- libssl-dev
- unixodbc-dev
ちなみにWindows版のバイナリは、特に依存関係はないので、そのまま実行できます。
0.60でパフォーマンスを上げたのですが、バグがぼろぼろ出まして修正しました。だいぶ品質が向上したかと思います。もっとも、もっと本格的なテストプログラムを記述しないとダメだと思いますが・・・そのノウハウの蓄積は今後に期待ですね・・・。
ただ一部の修正（メモリの管理関係）でパフォーマンスが下がったのでこのあたりはまた変更する必要があります。オープンソース＆マイナープロジェクトの良いところはバグを恐れずにガシガシ修正できるところですね、お金を頂戴するプロジェクトではここまで冒険はできません・・・。
また、今回のリリースではwol（Wake On Lan）述語（関数）も追加しています。文字通りWOLパケットを送出する述語です。
何でこんな述語を追加したのかと言いますと、
前回の記事のとおり最近モバイル環境を構築したのですが、これに加えてVPNを構築すると外部からイントラ環境にログオンすることができ、そうするとリモートディスクトップで私のマシンにログオンしたくなるのですが、ログオンするためには電源が入っていなければならず、とは言っても何時ログオンするかどうか解らないマシンの電源を入れっぱなしにする訳にもいかない、という訳でWOLで電源を入れることになり述語を追加しました。
WOLを送信するマシンは、LED電球並の消費電力のOpenBlocks600Dにすればよろしいでしょう。外部からはウエブから入るようにします。つまりブログビューアと同様にADPでWEBページをホストします。
というわけで、以下、WOLのコードになります。
wol.awp
#!/bin/adp -
<%;
+keycode("password"); # パスワードを指定
+machines("00-11-22-33-44-55", "machine1"); # MACアドレスとマシン名（適当でよい）を指定
+machines("66-77-88-99-aa-bb", "machine2"); # 複数あるときは同じように複数行にわたって記述する
+baddr("192.168.1.255"); # ブロードキャストアドレスを指定
,query("KEY").keycode, $mac =query("MAC"), wol($mac, =baddr);
%>
<html>
<head>
<meta http-equiv="Content-Language" content="ja">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>ネットワークブート</title>
</head>
<body>
ネットワークブート
<%,query("MAC",$mac),%><%=$mac%>BOOT中<%;%>
<br>
<form action="wol.awp" method="post" OnSubmit="return confirm('起動しますか？')">
キーコード：<input type="text" name="KEY" value=""><br>
起動マシン：
<select name="MAC">
<%,machines($mac, $name) ,%>
<option value="<%=$mac%>"><%=$name%>
<%,next;%>
</select>
<input type="submit" value="boot">
</form>
</body>
</html>
※2012/05/21 Ver 0.81のリリースにあわせて更新
ファイル名はwol.awpとします。form actionの引数を変えればファイル名自体はなんでも構いません（まぁ解らないようにした方がよい）が、拡張子はawpにする必要があります。
awpとは「Adp Web Page」の略で、ADPでWEBページをホストするモード（AWPモード）の拡張子になります。
Ver0.61では、拡張子がawpまたはcgiのみAWPモードになります。
これをApacheでcgiスクリプトとして、ホストすればOKなのですが、その前にスクリプト使い方の説明を、
先頭の３行目から６行目が設定になります。最低限のセキュリティということで、
パスワードの指定（３行目）と起動対象のマシンのMACアドレスと名前（４，５行目）と
起動対象のマシンがあるブロードキャストアドレスを指定（６行目）になります。
スクリプトの動作環境の設定ですが、PerlやPHPのCGIと同様にセットアップして頂けれたよいのですが、以下、apacheでのセットアップを簡単に説明します。
adpの実行ファイルを、/bin に保存します。/binがダメな方は、上記のスクリプトの1行目でadpのパスを指定します。
apacheのconfファイルですが、DirectoryのOptionsにExecCGIを追加し、AddHandlerで .awpを追加します。
以下、サンプルを載せます。
<Directory "/var/www/html">
Options FollowSymLinks ExecCGi +Includes
DirectoryIndex index.html index.php index.awp
AddHandler cgi-script .awp
AddHandler cgi-script .cgi
AllowOverride None
Order allow,deny
Allow from all
</Directory>
Windows＋IISでも動作可能です・・・設定方法は・・・まぁがんばってみて下さい。
（ご要望がありましたら設定方法を記載します・・・）
Windows7,2008R2に引き続き、これまた1年越しの作業になりましたが、我がohfuji.nameをホストするマシンをOpenBlockS 600（正確にはOpenBlockS 600D相当）に置き換えました。
OpenBlockS 600とは、ぷらっとホーム社さんが製造・販売しているマイクロサーバーで、
こちらが製品情報になります。ちなみに2月現在キャンペーンをやっておられます。
OpenBlockS 600自体の解説はいろいろな場所で行われているので、そちらにおまかせしますが、特質すべきは、抜群の低消費電力で、私がエコワットで測定した結果は9Wでした。またファンレスでストレージはコンパクトフラッシュを使うので音が出なくてかつ障害に強く、商業利用はもちろん、自宅サーバーとしても重宝するかと思います。
OSですが、OpenBlockS 600はSSD Linuxがプリインストールされています。また600DはDebianがプリインストールされています。メモリは1GB積んでいますのでDNSサーバーやメールサーバーとしては申し分ないスペックです。
難点が、CPUにPOWER-PCを使用しているところで、私のようなプログラミングをする人間にとっては開発環境を別途用意しないといけないのと、さらにそのCPUの動作周波数が600MHzとお世辞にも速いと言えないところで、Apacheで静的なページを運用するならともかく動的なページは難があるかと思います。特に普通のサーバーでも重たいWordpressをOpenBlockS 600で運用するのは厳しいかと思います。
では、このブログ（Wordpressなんですが・・）はどうしているのかと言いますと、このページはADPで作成したブログビューアーで表示しています。我がADPもOpen BlockS 600Dに移植しまして、このとおり動作しておる次第です。このページを頻繁に訪問される方は気がついておられたかと思いますが、最近Wordpressが重くなっていたので、どげんかせんといかんと思っておったところです。このような厳しい条件を克服するのはソフトウェアエンジニアとしてロマンを感じたりします。
しばらく運用してみてOKであれば、OpenBlockS 600D版のADPと共にブログビューアー（Adp WorPdress bLOG viewer － AWPLOG)のソースを公開しようかと思っております。
2011/06/23 追記：節電の為、自宅サーバー類は仮想マシンとして別のサーバーに集約しましたので、現在このサーバーはOpenBlocks 600D上では動作していません。
以前に書いた
この記事に関してコメントをもらいちょうど記事にしようかと思っていたところでしたので、ADPのキャッシュ機能を使い、
この記事の実験をADPでやったらどうなるかみてみます。
SQLでjoin（結合）と言えばSQLに慣れた方にとっては馴染み深いものですが、初心者にとっては一種の登竜門のようで、joinを避けたコードを見かけたりすることがあります（まぁ私も十数年前にはこのような理由でjoinを避けたコードを書いた記憶があります）。また、O/Rマッパーではテーブル毎にクラスを対応させる関係で、joinの取扱がややこしかったりします。
それ以外でも、私の場合になりますが、過去にパフォーマンス上の理由からjoinを行わなかったことがあります。
今回は、前回の実験と同様に
・SQLでjoinさせる。
・ADPでjoinさせる。
でパフォーマンスの違いについていくつかの実験を行い計測します。
実験環境
JOINのパフォーマンス実験環境はこちらに記述しています。
実験１ 素直にSQL側でjoinをさせたものを実行
例により、SQLで素直にjoinさせてみます。以下のようなコードになります。
,$db = "DSN=Trade"
,$str = "SELECT Price.CODE, RDATE, OPEN, CLOSE, NAME FROM Price "
"INNER JOIN Company ON (Price.CODE = Company.CODE)"
,sql@($db,$str,[]).csv.prtn,next;
少しコードの説明を、
1行目の、$db=～ の部分は、ODBCの接続文字列を指定します。上記のコードは、ODBCのデータソース名Tradeを指定している接続文字列になっています。
2,3行目の、$strの部分はSQL文を変数$strに代入しています。本来は1行で書けますが、wordpressで見やすいように2行で書いています。
4行目の
,sql@($db,$str,[]).csv.prtn,next;
sqlは組み込みの述語で、「ODBC-APIを使いsqlを実行し、結果を配列(@)で受け取り、csvに変換し、prtnで画面に出力し、nextで全ての結果を出力する」というコードになります。
自画自賛になりますが、必要最低限の情報だけで簡単にSQLが発行できているので、ADPの開発目標の一つである「SQLとの親和性が高い言語を目指す」を具現している例だと思います。
実行時間ですが、
D:\>adp -t sql_test_1.p > sql_test1.txt
time is 119192ms.
で、約119秒となりました。
実験２-Ａ ADP側でjoin(ネステッドループ）
続いて、ADP側でネステッドループjoinさせてみましょう。
,$db = "DSN=Trade"
,$price = "SELECT CODE,RDATE,OPEN,CLOSE FROM Price"
,$company = "SELECT NAME FROM Company WHERE CODE = ?"
,sql( $db, $price, [], @rec)
,sql( $db,$company, [$rec[0]], $name)
,csv($rec,$name).prtn,next;
ADPのDBライブラリは、前に紹介しました
ODBCライブラリがベースになっていますので、ODBCのパラメータクエリが使えます。
5行目のコードがパラメータクエリを使っています。
実行時間ですが、
D:\>adp -t sql_test_2.p > sql_test2.txt
time is 1717284ms.
で、約1717秒となりました。実験１と比べて約14倍の実行時間です。
実験２-Ｂ ADP側でjoin(ネステッドループ＆キャッシュ）
さらに続いて、ネステッドループjoinをADPのキャッシュ機能を使って高速化をはかります。
,$db = "DSN=Trade"
,$price = "SELECT CODE,RDATE,OPEN,CLOSE FROM Price"
,$company = "SELECT NAME FROM Company WHERE CODE = ?"
,sql( $db, $price, [], @rec)
,sql$( $db,$company, [$rec[0]], $name)
,csv($rec,$name).prtn,next;
呼び出し述語名の後ろに$をつければキャッシュ機能がONになります。上記のコードでは5行目の sql$ がキャッシュ機能を使用しています。
では、実行時間をみてみましょう。
D:\>adp -t sql_test_2.p > sql_test2.txt
time is 116770ms.
で、約117秒となりました。
実験２－Aと比べるとかなり高速化がはかられたかと思います。キャッシュのこのような使い方は、かなり有効だとうことが解るかと思います。繰り返しになりますが、ADPならお手軽にキャッシュ機能を使うことができます。
実験３ ADP側でjoin(事前にマップ作成）
ちなみに、ADPでも事前にマップを作成し、joinを行うことができます。
以下、コード例です。
,$db = "DSN=Trade"
,@tbl = {}
,sql($db, "SELECT CODE,NAME FROM Company",[], @r)
,@tbl = @tbl + [ $r["CODE"] | $r["NAME"] ]
,next
,sql($db, "SELECT CODE,RDATE,OPEN,CLOSE FROM Price",[],@rec)
,$key == $rec["CODE"].str
,csv($rec,$tbl[$key]).printn,next;
前回の記事ではC++でハッシュjoinを行うと書いたので『ハッシュJOINを言語で再開発するのは非効率』とコメントをもらいました。
コードを良く読んで頂ければ解るかと思いますが、実はC++の例でもjoin自体はプログラミング言語（ライブラリ）の機能を使っており、取り立てて複雑なことはしていません。
やっていることを説明しますと、マスターテーブル用のマップを事前に作成し、それを使ってjoinを行っています。慣れていない人にとっては難しいかもしれませんが、古くはperlの連想記憶、最近（これも古いが）の例ではVBScriptのディクショナリに相当します。DBMSを使わないで日常的にファイル処理を行っている方にとっては日常的なコードかと思います。
ちなみに、ADPのコード例ですが非常にすっきりとしているかと思います。C++の例と比べると本来やろうとしていることが明確になっているかと思います。
実行時間は、
D:\>adp -t sql_test_3.p > test3.txt
time is 110988ms.
で、約111秒とやはり実験１より速くなっていることが解ります。
こうしてみると、実験２-Ｂが思いのほか速くなっていないと思わるでしょう。
これはSQLの実行回数に関係しています。
各実験のSQLの実行回数を見てみましょう。
SQLの実行回数
| 実験１ | 1回 |
| 実験２－Ａ | 約470万回（Priceテーブルの行数+1） |
| 実験２－Ｂ | 約2000回（Companyテーブルの行数+1） |
| 実験３ | 2回 |
になります。実験２のコードではテーブルの行数に比例した数だけSQLを実行することになります。実験２－Ｂが実験２－Ａより速いのは、Priceテーブルの行数よりComapnyテーブルの行数が圧倒的に少ないから、つまり1対nの結合を行っているからで、仮に1対1の結合では速くならないということになります。
実験３がなぜ実験１より速いかですが、DBMS側から転送されるデータ量が違います。
以下、CSVファイルの先頭5行を表示します。
1717,2005-05-10 00:00:00.000,21251,3522,明豊ファシリティワークス(株)
1717,2005-05-11 00:00:00.000,21251,3522,明豊ファシリティワークス(株)
1717,2005-05-12 00:00:00.000,21251,3522,明豊ファシリティワークス(株)
1717,2005-05-13 00:00:00.000,21251,3522,明豊ファシリティワークス(株)
1717,2005-05-16 00:00:00.000,21251,3522,明豊ファシリティワークス(株)
企業名の『明豊ファシリティワークス(株)』が重複して余分なデータとなっています。実験１のコードではDBMSから言語側にこのように重複したデータが来ます。各実験で転送されるデータ量を見てみましょう。
結果データの転送量(CSVファイルベース)
| 実験１ | 約256MB |
| 実験２－Ａ | 約256MB |
| 実験２－Ｂ | 約184MB |
| 実験３ | 約184MB |
実は、DBMSから言語側へ転送されるデータ量自体は、実験１より実験２－Ｂの方が少なくなります。そのような関係で、実験１より実験２の方が早くなっています。SQLの実行回数（実験１の方がよい）とデータ転送量（実験２の方がよい）になりますが、このあたりはハードウェアの環境やDBMSによって結果が変わってくるでしょう。
この２つのデータから実験３は、なるべく少ないSQLの実行回数で少ないデータ量を転送しているということが解るかと思います。
追記：コメント欄での指摘およびテスト再現性を考慮してテスト環境を整備して再度計測しています。
バージョンが0.5Xから0.6に変わりましたが、機能的には特に変わりません。
前回のリリースから継続的に実行性能の強化をしてまして、だいぶ速くなったので一旦リリースします。
どこまで速くなったかですが、ADP 0.60と各ブラウザとのフィボナッチ数列を求めるプログラムの実行時間の比較を行います。
ちなみに、JavaScriptのコードですが、
こちらにあるコードを使わせていただきました。
ADP側のコードは、以下のとおりです（高速化のためには元のソースも変更する必要がありましたので前とは若干変わっています）。
+fib(0,0),!;
+fib(1,1),!;
+fib($x,$y),fib($x - 1, $f1),fib($x - 2, $f2), $y == $f1 + $f2, !;
,fib(28).printn;
◆マシン
・CPU Core i7-980X
・メモリ 24GB（DDR3-1066 4GB × 6）
・OS Windows 7 Ulitimate (x64)
◆結果
28のフィボナッチ数列を求める時間
| IE8（64ビット版） | 368ミリ秒 |
| FireFox 3.6.13 | 167ミリ秒 |
| Google Chrome 8.0.552.224 | 9ミリ秒 |
| ADP 0.60 | 226ミリ秒 |
ADP 0.60の結果ですが、
IE8以上、FireFox3.6未満という結果になりました。個人的にはまだまだ不満足ですが、競争が激しくなったブラウザのJavaScriptとそう遜色がない結果になっているのでひとまず納得しておきます。
またGoogle Chromeの結果が突出していますが、これはJITコンパイラが利いているかと思います。この手のベンチマークの結果を誤解してほしくないので書いておきますとどんなプログラムも常にGoogle Chromeが突出して速いと言っているわけではござませんので結果を丸々鵜呑みにしないように注意してください
（実際の体感速度は皆様が使ってみて判断してください・・・）。
で、ここまでくると
『いったいどこまで速くなるのか？』
と疑問に思われるでしょう。というわけで、アセンブラ（正確にはインラインアセンブラ）のコードと実行結果を載せます。
#include <iostream>
using namespace std;
#if 0
int __fastcall fib(int f)
{
if ( f == 0 ) return f;
if ( f == 1 ) return f;
return fib(f-1) + fib(f-2);
}
#else
extern "C" {
int __declspec(naked) __fastcall fib(int f)
{
__asm push esi
__asm mov eax, ecx
__asm cmp ecx, 0
__asm je _return
__asm cmp ecx, 1
__asm je _return
__asm dec ecx
__asm call fib
__asm mov esi, eax
__asm dec ecx
__asm call fib
__asm add eax, esi
__asm add ecx, 2
_return:
__asm pop esi
__asm ret
}
}
#endif
int main(int argc, _TCHAR* argv[])
{
clock_t c = clock();
cout << "fib = " << fib(28) << endl;
cout << "Execute time is = " << (clock()-c)*1000.0/CLOCKS_PER_SEC << endl;
return 0;
}
プリプロセッサでアセンブラコードが動くようにしていますが、コードはC言語との比較もできるようにCのコードも掲載しています。Visual Studio 2008でコンパイル実行できます。実行時間は4m秒でした。ちなみに、フィボナッチ数例自体を高速に求める方法は他にあります。以前の例のようにADPキャッシュを使えば数ミリ秒になります。ここでは再起関数の呼び出し回数を変えないようにして各プログラミング言語自体が持つ基本的な速度について比較できるようにしています。