Warning: Can’t synchronize with the repository
(Unsupported version control system “svn”: “No module named svn”
). Look in the Trac log for more information.

ログを見たらmod_pythonモジュールがリポジトリと同期できないよ、
って言ってるみたい。

# cd /usr/local/src/subversion-1.6.2
# make swig-py
# make install-swig-py
# vim [site-packagesディレクトリ]/svn-python.pth
/usr/local/lib/svn-python
# ln -s /usr/local/lib/python2.6/site-packages/svn [site-packagesディレクトリ]
# ln -s /usr/local/lib/python2.6/site-packages/libsvn [site-packagesディレクトリ]

zopeのトップページをベンチマークすると秒間63くらい
リクエストをさばいてます。

# ab -n 100 -c 10 http://192.168.0.10:8080/
This is ApacheBench, Version 2.0.40-dev < $Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/

Benchmarking 192.168.0.10 (be patient)…..done

Server Software: Zope/(Zope
Server Hostname: 192.168.0.10
Server Port: 8080

Document Path: /
Document Length: 2717 bytes

Concurrency Level: 10
Time taken for tests: 1.575463 seconds
Complete requests: 100
Failed requests: 0
Write errors: 0
Total transferred: 294000 bytes
HTML transferred: 271700 bytes
Requests per second: 63.47 [#/sec] (mean)
Time per request: 157.546 [ms] (mean)
Time per request: 15.755 [ms] (mean, across all concurrent requests)
Transfer rate: 182.17 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.1 0 1
Processing: 21 147 37.7 152 301
Waiting: 7 138 38.7 142 292
Total: 21 147 37.7 152 301

Percentage of the requests served within a certain time (ms)
50% 152
66% 153
75% 153
80% 159
90% 168
95% 169
98% 298
99% 301
100% 301 (longest request)

ところがploneサイトをベンチマークすると秒間２リクエストくらい
しかさばけないようです。

# ab -n 100 -c 10 http://192.168.0.10:8080/
This is ApacheBench, Version 2.0.40-dev < $Revision: 1.146 $>
apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/

Benchmarking 192.168.0.10 (be patient)…..done

Server Software: Zope/(Zope
Server Hostname: 192.168.0.10
Server Port: 8080

Document Path: /demo1
Document Length: 20658 bytes

Concurrency Level: 10
Time taken for tests: 44.151914 seconds
Complete requests: 100
Failed requests: 0
Write errors: 0
Total transferred: 2093600 bytes
HTML transferred: 2065800 bytes
Requests per second: 2.26 [#/sec] (mean)
Time per request: 4415.191 [ms] (mean)
Time per request: 441.519 [ms] (mean, across all concurrent requests)
Transfer rate: 46.29 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.1 0 1
Processing: 619 4214 7093.6 2820 44069
Waiting: 536 4207 7094.5 2815 44067
Total: 620 4214 7093.6 2820 44069

Percentage of the requests served within a certain time (ms)
50% 2820
66% 3551
75% 4113
80% 4259
90% 4532
95% 5713
98% 43913
99% 44069
100% 44069 (longest request)

Ploneは重たいですがZope自体は自前のWEBサーバを持っていることも
あり、予想以上に軽いことがわかりました。

FreeBSDの場合はportsから最新のPythonを入れると2.5.1なので
/usr/opt/python24 にPython2.4.4を別途入れる。FreeBSDの
スレッドスタックはデフォルトで小さすぎるのでWANT_HUGE_STACK_SIZE
オプションを付けてmakeしないと、zopeのインスタンスホームに
python.coreができることになってしまうと INSTALL.txtに書いてある。

# ./configure –with-threads
# make WANT_HUGE_STACK_SIZE=yes
# make install

ところがこれではうまくいかなかった。スレッドのスタックが大きく
なっていないみたいだ。Pythonのソースをgrepしても
そのオプションは見つからない。

仕方ないのでportsのMakefileを見ると、HUGE_STACK_SIZE=yes だと
CFLAGに -DTHREAD_STACK_SIZE=0x100000 としている。どうもこっちの
方が確実そうなので、configureスクリプトが生成したMakefileの
OPTに-DTHREAD_STACK_SIZE=0x100000 を足してみた。そして普通に
make, make install 。今度は大丈夫そうだ。

スレッドスタックの大きさの確認方法は以下のとおり。
結果が1000ならたぶんうまくいく、ということらしい。
おそらくFreeBSD6.xなどでは初めから問題ないみたいなのだが、
サーバがFreeBSD4.11(古すぎ)なので問題がみたい。
「How can I make sure my BSD Python has enough stack?」

# python
Python 2.4.4 (#1, Sep 5 2007, 14:15:24)
[GCC 2.95.4 20020320 [FreeBSD]] on freebsd4
Type “help”, “copyright”, “credits” or “license” for more information.
>>> import sys
>>> sys.getrecursionlimit()
1000

Plone3.0を動かす場合に必要になるPythonライブラリを先に入れておく。

• PIL(Python Imaging Library) 1.1.5 or newer
• Python ElementTree

PloneはベースになるZopeのバージョンにうるさい。Plone3.0の場合は
Zopeは2.10.4以上でないと動かない。Zope2.11.x系列やZope3.0系列は
だめ。今回は /usr/opt/zope2.10.4 にインストールする。

# cd /usr/local/src
# wget http://www.zope.org/Products/Zope/2.10.4/Zope-2.10.4-final.tgz
# tar xvfz Zope-2.10.4-final.tgz
# cd Zope-2.10.4-final
# ./configure –prefix=/usr/opt/zope2.10.4
–with-python=/usr/opt/python24/bin/python
–optimize
# make
# make install

やっとPlone3.0のインストールだ。/usr/opt/Plone-3.0にインストール
することにした。Productsとlibの中身をそれぞれコピーしてもいいけど
たぶん将来見たときPloneのどのバージョンかわからなくなるので、
シンボリックリンクの方が好み。

# cd /usr/opt
# wget http://plone.googlecode.com/files/Plone-3.0.tar.gz
# tar xvfz Plone-3.0.tar.gz
# cd Plone-3.0

# ln -s /usr/opt/Plone-3.0/lib/python/*
/usr/opt/zope2.10.4/lib/python/

# ln -s /usr/opt/Plone-3.0/Products/*
/usr/opt/zope2.10.4/Products/

ここまで来たらZopeのインスタンスを作れる。

# /usr/opt/zope2.10.4/bin/mkzopeinstance.py

このままではアクセスするのにポート番号が必要になるので、
適当なホスト名をDNSに設定して、apache側でProxyPassディレクティブ
を使って、Proxy経由でアクセスできるようにした方がかっこいいかも。

http://192.168.0.10:8080/

httpd.conf

ServerName plonedemo.hogehoge.com
ProxyPass / http://localhost:8080/VirtualHostBase/http/plonedemo.hogehoge.com:80/V
irtualHostRoot/

で最初にアクセスするとなんだか30秒近く待たされる。重すぎだろ・・

でもそれ以降はまあまあサクサク動きます。

[root@sv]~# portsdb -Uu
Updating the ports index … Generating INDEX.tmp - please wait.."/usr/ports/audio/gstreamer-plugins-esound/../../
multimedia/gstreamer-plugins/Makefile.common”, line 392: Malformed conditional (${gst_${GST_PLUGIN}_GCONF_SCHEMAS}!="")
“/usr/ports/audio/gstreamer-plugins-esound/../../multimedia/
gstreamer-plugins/Makefile.common”, line 396: Malformed conditional (${gst_${GST_PLUGIN}_USE_SDL}!="")
“/usr/ports/audio/gstreamer-plugins-esound/../../multimedia/
gstreamer-plugins/Makefile.common”, line 398: if-less endif
“/usr/ports/audio/gstreamer-plugins-esound/../../multimedia/
gstreamer-plugins/Makefile.common”, line 398: Need an operator
“/usr/ports/audio/gstreamer-plugins-esound/../../multimedia/
gstreamer-plugins/Makefile.common”, line 419: if-less endif
“/usr/ports/audio/gstreamer-plugins-esound/../../multimedia/
gstreamer-plugins/Makefile.common”, line 419: Need an operator
make: fatal errors encountered – cannot continue
===> audio/gstreamer-plugins-esound failed
*** Error code 1
1 error

FreeBSDの4系ではこれらの変数が使われる時にはまだ初期化されて
いないようだ。

portsのメーリングリストにパッチが公開されていた。

ports/104500: [PATCH] multimedia/gstreamer-plugins/Makefile.common breaks make index

rubyとgemがインストールされているシステムならばrailsの
インストールは簡単だ。gemがない場合はここからダウンロードする。

# gem install rails –remote –include-dependencies

これだけで依存関係を解決してインストールしてくれる。

データベースにはMySQLかPostgreSQLが良いだろう。今の時点では
SQLiteはマイグレーションに対応していない。ここではMySQL/Ruby
を試してみる。

# gem install mysql –with-mysql-dir=/usr/opt/mysql50

最初「gem install mysql」してハマった。MySQLのパスが
/usr/opt/mysql50と普通と違ったのでリンクがうまくいって
なかった。でも特にエラーが出なかったので気がつかなかった。
railsを実行してみると

その後、上記のコマンドで無事MySQL/Rubyがロードできるように
なった。

scaffoldを使ってすぐにおかしいと気がついたのはレコードの
削除ができないってこと。PostgreSQL8.1.4とSQLite3で試して
みたがやはり削除できない。エラーも出ないし、何も起こらない。
実はrailsでscaffoldで生成されたページからレコードを削除する
ためにはブラウザにJavaScriptが必要だった。FirefoxのNoScript
エクステンションがアダとなった形だ。

最初はWEBRickで簡単なアプリケーションを作ってみた。そして
ベンチマークしてみるとWEBrickだと僕のPC(AthronXP1500程度)で
秒間5回前後のリクエストに応えられた。apacheからXOOOPSを使う
よりも少し軽い感じ。

次にrailsをCGIとしてベンチマークしてみると予想通り使い物に
ならない重さで、秒間0.3回程度のリクエスト処理が限界だった。
そうなると1ページ出力するのに3秒以上かかるわけでストレスが
たまりまくりとなる。

仕方ないのでapache2にFastCGIを組み込んでみたら秒間5回前後の
リクエストを処理できるようになった。これならまあ使える。

問題１:Accessが頻繁に落ちるようになる
前回触れた問題だがまだ直っていない(もう直してもらえないかも？)

問題２：最新のMySQL ODBCドライバではMySQLのリンクテーブル(文字コード cp932)が不安定になる
普通に最新のMySQL ODBCドライバをインストールした状態で、Accessを
起動してテーブルビューでMySQLリンクテーブルを見ると、開けないもの
がある。

このシステムの文字コードがcp932であることも関係あるかもしれない。
おそらくMySQLに限らずShift_JIS系の文字コードは使うべきではないの
だろう。しかし「set names cp932;」などとしても問題は解決しない。

対策はmyodbc3.dll をsjis対応の古いものに差し替えるしかない。

上記の問題はあるものの解決可能なので、ストアドプロシージャや
VIEW、クライアントの文字コード指定(set names)などバージョン
アップでできることの幅が増えた。

あまり開発は活発ではないようだけどインストールして試してみた。

blosxom/pyblosxomと比較すると

+ まだプラグイン(moduleと呼んでる)があまりない
+ トラックバックを初期状態で含んでいる

○プラグインの実装
blosxom.phpのプラグインはちょっと変わっている。プラグインの
ファイルは「plugin.php」のような名前だ。(py)blosxomとは違って
プラグインはクラスやパッケージではなく、ただの関数をいくつか
定義するだけだ。

プラグインを登録するにはディレクトリ(modules）に入れるだけで
なく、設定ファイル(conf.php)の $modules という名前の配列に
登録しておかないといけない。

最初「ん？」と思ったのが、このサイトはMovableTypeでできている
ようだが、パーマリンクのURLを見ると .php で終わっている？
なんだか不思議だなと思った。

閑話休題。
そこで初めて知ったのはXOOPSのリダイレクト画面をなくすことで
高速化できるという記事。このhackはすごく良いアイデアだと思う。
このサイトのXOOPSにも導入してみた。

リダイレクトの画面がない分、体感的に明らかに速い。

設定自体はとても簡単だ。/home/me/public_html/blosxom が
blosxomのディレクトリだとすると別途、静的なページ用の
ディレクトリ(例えば /home/me/public_html/blog )を作り
以下のように設定するだけだ。

# — Static Rendering —–
$static_dir = ‘/home/me/public_html/blog’;
$static_password = “secret”;
@static_flavours = qw/html rss/;
$static_entries = 1;

○静的なページ生成の問題
しかしいきなり問題が発生した。デフォルト設定のままで $url
を自動設定(すなわち空文字)にしていたら、静的に生成したページの
カレンダやカテゴリ、アーカイブからエントリへのリンクがおかしい。
ホスト名がなぜか「localhost」になっている。

コードを見てると CGIモジュールのurl()関数でホスト名を
取得するんだけど、コマンドラインから静的なページを
生成するため、localhost が入ってしまう。

○$urlを直接指定したら？
それだと使い物にならないので $url を空文字列からディレクトリ
(静的なページを配置するディレクトリ)にしたら、静的なページ側
では問題なくなったけれど、今度は動的なblosxom.cgiの方で、
カレンダやカテゴリ、アーカイブからエントリへのリンクが
静的なページに向いてしまうので、これまた具合が悪い。

僕がやりたいのは、動的なディレクトリではすべてのリンクが
動的ページを指していて、別途公開用の静的なページでは
トラックバックやページ編集(WikiEditish)以外のページは
静的なページを指して欲しいのだ。

○結論：別の変数が必要だ
スクリプトの100行目付近で $static_or_dynamic という変数が
セットされるので、この中身によって$urlを変える必要がある。
$urlは空にして自動設定にしておいて、以下のようにする。

# コードの上の方で定義しておく
$static_url = “http://www.mysite.com/blog”; # 静的ページのURL

# $static_or_dynamic が定義された後、$urlが空ならば
# おかしくなるのは静的(static)の場合だけ
$url = $static_url if ($static_or_dynamic
eq “static” and $url =~ m!http://localhost!);

そしてフレーバー内では $url を使うことでなんとか動いてます。

でもかなり枯れてきているはずのblosxom2でこんな修正が必要とも
思えない。なんだか根本的な理解不足があるような気がしてならない。

「ExtensionManager」というExtensionを
インストールするとFirebirdみたいに
Extensionを管理できるようになった。