Digitune [memo]

「ヨコハマ買い出し紀行(11)」

指輪物語の方はいよいよ佳境¹ですが、これも合間に読んだマンガ。うちの妹なんかに言わせると「あざとくて嫌い」なんだそうですが、僕はなんだかんだいいつつ最初から読んでます。

ところでこのマンガもいわゆる「終末」、人類の黄昏を描いたものだと言うことになっていたと思います。最近、このタイプの「終末」話、「ナウシカ」なんかもそうですが、人類の力が衰退して徐々に自然に圧倒されていく話に、微妙な違和感を感じるのです。

今の僕には、このタイプの「終末」感には、自然に対する甘えがあるような気がしてならないんですよね。人類がいくら幼く未熟で傍若無人を働いた (その結果自ら滅びの道に入り込んだ) としても、自然はそれを全て受け止め、最終的には全てを元の通り癒してくれる、という虫の良い希望が含まれているように思うのです。「ナウシカ」の腐海や王蟲なんかは、思いっきりそういう、時に厳しく、時に優しい包容力のある存在として描かれていますよね。

でもそれって無邪気に期待できることでしょうか。自然、って、なんとなく一つの大きな主体のように感じてしまいがちですが、実際には小さな循環系、自己組織系の集まりです。そして当然ながら、人間もそこに組み込まれています。「人」とは別に「自然」という主体があるわけじゃなくて、人は自然の一部なわけです。当たり前ですけど。

人が自然の一部である以上、人の成した結果こそが自然の未来である、ということになるのではないでしょうか。自らの成していることをきちんと認識せずに、いたずらに多様性を奪ったり環境を変化させたりしていると、自然はそれを鏡のように反映するでしょう。「人間のやることなんて」という過小評価は、バタフライ効果によって否定されるでしょう。自然、いわゆる生物圏は完全なカオス系ではありませんが、かといって変化がすぐに静まってしまう秩序系でもありません。

もし人類にゆるやかな終末が訪れるとしても²、たぶんそれは「自然による救済」などではなく、それまでの業に真っ正面から向き合わされるものになるのではないか、それも腐海や王蟲のような慈愛に溢れたものではなく非常に冷酷な現実として、と僕は思うのです。

その後の Opteron

Fedora Core 1 for x86_64 入れてみましたよ。さらにとんでもなく速くなった処理あり、かえって遅くなってしまったものあり。安定性なども含めてトータルで考えると 64bit Llinux の価値は現在のところまだ微妙ですね…¹。

その後の PSX

２回めのアップグレード後、ゲームを起動するタイミングや市販の DVD を見ようとするタイミングで、「しばらくお待ちください」と言いながら静かに電源が OFF になってしまうことがあるような。「あれ？」と思いながら電源再投入すると普通に動くんですけどね。
フラッシュ操作時や通常再生時にもごくまれに、再生が突っかかるようになった気も。こっちはそろそろ HDD が満タンになりそうなことと相関があるのかなぁ。

Opteron 速っ！

Opteron 248 (2.2GHz) ×2、というマシンの評価をする機会があったんですが、これがとんでもなく速い。比較用に使った Xeon 3.06GHz×2、というマシンと比べても (当然 Xeon マシンは HT enable です)、apache bench、pgbench (PostgreSQL)、Java による CPU 処理など一般的なサーバが行う処理についてはほぼ全勝、モノによっては倍くらい速いものも。しかもこれは Xeon マシンと同じ RedHat Enterprise Linux 3、つまり 32bit OS 上での結果なのですから、またびっくりです。Fedora Core 1 (x86_64) や SuSE Linux 9 (x86_64) のような 64bit 環境だとどうなっちゃうんだろう…。
サーバ用ハードウェアって単純に性能だけで決められないことも多いから、２倍の性能を持っていることがすぐにシェア拡大にはつながらないでしょうが、同じくらいの価格で倍くらいの性能が得られるとなると、徐々に稼働実績も出来てきたら、そのうち Opteron を選ばない手はない、って話になっても不思議じゃないなぁ。

SuSE Linux

カメレオン好きの僕としては最近 SuSE が気になっています¹。Sun の Java Desktop System のベースも SuSE だそうで。もうすぐリリースの 9.1 では 2.6 Kernel も入るみたいだし、ちょっと使ってみようかなぁ…²。
ところであのカメレオンはかわいいと思うんだけど、KDE のデフォルトテーマが、全 Window の横っちょにカメレオンの顔がくっつくオリジナルなものなのはちょっと鬱陶しいと思うゾ。

ハッブル壁紙集

K.Moriyama さんとこやひびきさんとこより。綺麗ですねぇ…。

風邪

昨日くらいから風邪で全然声が出なくなってしまった。まともにしゃべれない、というのは結構ツライ。思わず電話に出た時とか、話が全然通じなくて切なくなります。
昨日までは声が出ないだけであんまり具合悪くはなかったんですが、今日になって下痢＋気持ち悪さが増大中。明日お休みしようかしら…。

集中力

僕もあんまり集中力ない方で、自発的に集中状態に入れない時¹って結構あるんですけど、状況によってはあえて脳味噌を停止して無理矢理集中状態に持っていかざるを得ないことがあります。
そういう時によく僕たち (僕やはかせ) が使っていた表現が「息を止めてコードを書く」。「今から息止めるから話しかけないでね」とか「ぷはーやっと息が出来るよ…」とか「とりあえず息止めて書いちゃって」という感じで使います。
僕にとっては感覚的にぴったんこな表現でした。

エイプリルフール

ネタ、思いつかんかった…。直球勝負人生だからして、ジョーク考えるのって苦手なんだよね＞SAK。
今年はあんまりいいネタがない気がするなぁ。Google のフリーメールサービス、「Gmail」のメールボックス容量が 1Gbytes、というニュースに驚いてたら、SAK が「エイプリルフールじゃない？」って言ったのが一番面白かったかも。

「千石屋綺談」

電車ではここのところずっと「指輪物語」を読んでいるのですが、マンガはちょこちょこ読んでます。その中の一冊。

「いつになく苦い話を集めてしまったシリーズです」なんて作者の言葉に少し身構えてしまったんですが、それほど苦しい話というわけでもなく、少しホッとしたり。総じてこの人のいつものお話です。

「損得勘定がないの。そういう人は幸せになれるわ。」という言葉には、ありきたりながら我が身を振り返らずにはいられませんでした。

ICO 開発者の話

とても興味深かった。目指す「リアリティ」に到達できないフィーチャーはどんどん削っていく「サブトラクティング・デザイン」は、従来のソフトウェア開発現場から見るときっと目から鱗な話なんじゃないでしょうか。Unified Process を学んだ時にも、「ソフトウェアは自由度が非常に高いがゆえに、クライアントから次々湧いてくる要求をどう管理するかが非常に重要」という話があり、僕の経験上も開発期間中は主に機能を追加する方向にしか向かったことがないように思います¹。
機能を削る方向へは、ソフトウェアをリリース後ある程度実働期間を経た後に、明らかに不必要な機能、冗長な機能などに対して行われることが多い気がしますが、「ICO」はたぶん、4年間という一本のゲーム開発としては長い期間の間に、何度か「擬似リリース」を繰り返し、内容を洗練させていったのではないかと想像します。
思い出してみると、ねおんさんはこの「サブトラクティング・デザイン」を結構意識されてたんじゃないかと思ったりして…。
他にも、節目節目でデモ・ムービーを製作し、自分達の目指す方向性を関係者に対して誤解のないよう継続的に示し続けた話などは、ゲームに限らずソフトウェア開発一般の話として、とても大事だと思いました。僕も今業務時間のほとんどを意識合わせのための資料作りに費やしていますが、「目指している方向性を継続的に資料化して関係者に示す」ことの重要性を日々実感している毎日です。
ところで、同じ GAME Watch のこちらの桜井氏の意見は、僕としてはイマイチ。クレヨンしんちゃんじゃないけど、「そーともゆー」って感じ(ワケワカ。

redraw ポリシー

僕は普段、KDE 環境で生活しているんですが、KDE/QT 環境の redraw ポリシーって微妙にダサい。ふとした拍子にチラチラとフリッカーが見られます。個人的に、そのことがなんとなーく信用できない感じに繋がっているような気も。Konqueror は Explorer と (File Viewer として) ほとんど変わらない機能を持っているんですが、どうも積極的に使う気にならないのはその辺に理由があるような…。

XNA の思想

あははははは。ねおんさんからのこのツッコミ、

XNAの彼は、ビジネスというものについてはイマイチなので、そのあたりの発言は許して上げるようにw

ねおんさんのつっこみより引用

は、個人的にとてもツボでした。まさにその点を突っ込もうかと思っていたので。

さて気を取り直して。僕もこの記事をとても興味深く読みました。この記事を読んで僕が思ったことは二つ。一つはねおんさんも指摘されているビジネス的な面、そしてもう一つは、やっぱり Microsoft はソフトウェアの会社であるのだなぁ、ということ。

この記事を読むと、Microsoft は、3/27 の僕の意見で言うところの「モデル規定者」の立場を明確に指向しているように見えます。現状、XNA について語られる言葉では、必要以上に「開発環境」というものが強調されているように僕は感じますが、その裏には「プログラミングモデル」自体を構築していこう、というソフト屋の意図がありありとうかがえます。

実は XNA の考え方は、Allard さんが Win32 API との対比を行っていることからも分かるように、Microsoft が昔から行ってきたことでもあるんですよね。かつて Microsoft は、Windows API (GDI やドライバモデル) を規定した上で、オープンな土俵でハードウェアベンダーに競争させることで、より最適化されたハードウェアの発展をドライブし、また DirectX によって同様に 3D グラフィックスハードウェアの発展をドライブしてきました。もちろん、彼らはそれぞれと並行して (それら下位レイヤーからのフィードバックを受けて) モデル自体のブラッシュアップも精力的に行ってきました。この手の物事の進め方についてはお手の物なのでしょうね。

さて、XNA のスコープにおける直接のライバル、SCEI の場合はどうか、というと、実はそういう「モデル発展のフィードバック」を作ることがすごく下手なんじゃないかと思うんですよね。PS の時は SGI という先行者がいたために、プログラミングモデル的には単にそれをなぞればよく、成功の要因は主にタイミングと思い切りのいいハードウェア設計、それに流通改革にありました。PS2 の時も基本的な方向性は PS のころと変えずに単にそれをスケールアップしただけで、PS2 ならではの新しい方向性の提案 (eDRAM による超広帯域 framebuffer とか、VU とか、ある種特異なメモリモデルとか) も、結果的に見るとどうもあさっての方向を向いていたようです。外し具合がたまたま致命的なものではなかったためになんとか成功している、という状況でしょう。

僕が気になるのは、Microsoft が PC の世界というオープンな環境で自らのモデルを提案し、日々ブラッシュアップしていっているのに対し、SCEI はそうしていないように見える点です。そのことは、基本的にオープンな DirectX ベースのプログラミングモデルが載せられることがはっきりしている Xbox2 と、IBM と共に完全な密室で作成していてどんなものになるのか見当もつかない次世代 PS (Cell マシン) の違いを見ても強く感じます。

プログラミングモデル、なんていうものは、「いかに多くの人に理解してもらい、使ってもらえるか」が勝負なわけで、開かれた環境で広く議論され、叩かれた方が良いものが出来ることは明らかだと思うんですが、SCEI にはそういった議論を起こそうという方向性は見えません。出て来るのはなんだか抽象的な話ばかりで、とても議論に耐えうるような情報ではありません。これはうまくない。

確かに、「モデルの実装」という世界ではパテントが全てを支配し秘密主義にも意味があるでしょう。しかし、こと「モデル」の構築を考えた時には、秘密主義は百害あって一利なしなように思えます。

その実装面にしても SCEI は分が悪い状況にあります。秘密主義を取っている SCEI は、全てのイノベーションを SCEI 内で起こす必要があります。ところが Microsoft は、自らの提示したモデルをもっとも良く実装したハードウェアベンダーの製品を選んで使うことが出来ます²。開発者の量が桁違いです。

そういう状況を考えると、次世代 PS が成功するには、そうとう天才的な人が現れて革新的なモデルを提案するか (Cell の伝えられている極めて特殊な構成を見るとこちらを期待したくなりますが、PS2 の時のように思いっきり外す可能性も高いよなぁ…)、または技術面とは全く別のところで相当うまく立ち回る必要があるんじゃないかなぁ、と悲観的になりますね。「PC の世界に深く入り込んでしまっているがゆえに見えなくなっている点」というのもなさそうだしなぁ。そういうモノがあったとしてもたまたま今はまだ注目されていないだけだろうし…。

ビジネス面について一点だけ。Allard さんの言う「開かれた開発環境」を実現するには、現在のコンシューマゲーム機におけるクローズドライセンスモデルではないものを考える必要がありますが、Microsoft はもうずいぶん前からもっと開かれたモデル、つまりオープンな規格の上で、他より価値の高いものを提供することで利益を得る、というよりシンプルなモデルを指向してきているように僕には思えます。ので Allard さんの今後の行方には結構期待!

p.s. マネージャとしてのご忠言、どうもありがとうございます。とても参考になりました。

PSX アップグレード第二弾

今回はノーエラーで無事に終わりました。1.3倍再生はなかなか面白い。またしばらく様子を見てみます。

鬱陶しいログ

apache のログに、

xxx.xxx.xxx.xxx - - [26/Feb/2004:15:56:54 +0900] "SEARCH /\x90\x02\xb1...  

で始まるアクセスがウチのサイトにしてはたくさん記録されてて (しかも１行が文字数にして 32806 文字もある)、おかげでログファイルの容量が先週分と今週分で 40Mbytes 超えてる。調べてみたら、上の時刻 (2004/02/26 15:56:54) くらいから始まってるみたい？先週から急に増えてる？といっても先週は一週間で500件くらいだけど…。今週は二日で既に 500 件超。

送信元がまちまちであるところからたぶん worm なんだと思うんだけど、イマイチ確たる情報が得られない。去年の4月に fix されてる IIS の穴が関係してる、という記述は見つかったんだけど…。

apache の名誉挽回

イマイチ結果に納得できなかったので、

• prefork MPM な apache2
• 手元でコンパイル、ほとんどデフォルト設定の apache1.3

でも試してみたところ、小さなファイルでは全て一昨日の apache2 worker MPM とほぼ同等の性能が出ました¹。やっぱり速いじゃん、apache。

ところで大きなファイルの場合は、手元でコンパイルしたデフォルト設定のものでも apache2 と apache1.3 の間には大きな差があり、大きなファイルの転送時の効率は apache2 の方が明らかに良さそうでした。

woody 標準の apache が遅い原因はまだちゃんと調べてませんが、考えてみたらバイナリは標準とはいえ、設定については name based virtual host の設定とかされてたりしてあんまり標準的ではないことに気がついたりして…。

ベンチマークは難しいね、やっぱり(汗。

ゲームマシンのアーキテクチャ

マイクロソフトの「XNA」が発表になったりしましたが、次世代 PS 等将来のゲームマシン、というかエンタテインメントマシンのアーキテクチャについてふと考えてみました。
「エンタテインメント」²の本質が「体験を通して感情を動かすこと」だとすれば、物理デバイスと切り離されたファミコン以降のゲーム機が目指さなければならない方向のうち、もっとも計算量が必要な方向は「計算的に現実感を創出する」という方向です。ちなみにイノヴェイティブな手法でピンポイントにとんでもない「リアリティ」を生むことも可能なわけですけれども、そちらはマシン・アーキテクチャとの相関がそれほど高くない (必ずしも計算量を必要としない) のでとりあえず置いておきます。
「現実感創出」のための一つのピース、3D グラフィックスのクオリティ向上に向けては、昨今の PC ゲームの世界を見ていても、nVidia vs. ATI を始めとして各ソフトウェアベンダー間でも極めて競争が過酷なこともあり、相当スゴイ世界が繰り広げられていますが、もう一つのピース、物理シミュレーション系の話は、Half-Life2 など一部そういったことを売りにし始めているゲームも出てきているとはいえ、まだ 3D グラフィックスほどの盛り上がりが見られません。
将来のゲームマシンには、「物理シミュレーションを効率良く実行する」という特性がある種必須なのではないかと僕には思えるのですが、これって今の PC のアーキテクチャの延長線上で考えるのは難しいんじゃないかと思うんですよね。根拠はまったくなくて、強いて言えば「(将来構築される物理シミュレーションモデルはきっと) 並列度が極端に高い処理だろう」、と僕が想像しているからだけなんですけど。
えーとつまり、3D グラフィックスがシェーダモデルを構築しそれに最適化されたハードウェアを生み出してきたように、物理シミュレーションの世界でも何らかの計算モデルを構築し、それに最適化されたハードウェアを設計する…という流れが出て来るんじゃないかと想像しているわけです。
次世代 PS に搭載される予定の「Cell」が、そこまで考えられて作られているといいんだけど (例えば、順序は逆だけど初めから Cell に最適化された物理シミュレーションモデルが用意されている、とか…)、うーん、なんとなくビミョー(笑。

ありえない

六本木ヒルズで起きた回転扉での死亡事故について、ドアに挟まれることを防止するセンサーに死角があった、との報道が。
もし本当だとしたらとんでもない話です。その「安全装置」の設計者は、何を守るべきかを全く理解できていなかったとしか思えない。
昨今の情報漏洩事件での漏洩させた当事者の弁に、「(もし情報漏洩させたことが注意義務違反に当たるなら) ガチガチのセキュリティをかけているごく一部の上場企業以外は、どこも個人情報を扱うことが困難になるのではないかとも思う。」なんて話が出ていて失笑したんですが、これも同じですよね。何を守るべきなのか、をきちんと理解していれば、(一部上場企業にしか賄えないほどの・笑) 無尽蔵にコストがかかることなんてなくて、現実的なレベルに落とし込むことが可能なはずです。
なんとなーく「安全装置が必要と言われたので付けました」とか「とりあえずよく分からないけど SSL にしましたから安心です」というレベルの認識で設計されている気がするなぁ。仮にもエンジニアなら、その「設計の意図」を胸を張って説明出来るくらいでいて欲しい。トレードオフに埋もれた現実も理解出来るけど、かといって本質を見失ってはどうしようもないよ…。

昨日の追記

昨日のテストは非常に小さいファイルで実験してたわけですが、これを例えば 1Mbytes のファイルにしてみると、また全然違った結果が得られます。

apache では

kazawa@tpx20:~$ ab -c 20 -n 1000 http://localhost/dummy.dat  
This is ApacheBench, Version 1.3d <$Revision: 1.65 $> apache-1.3  
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/  
Copyright (c) 1998-2002 The Apache Software Foundation, http://www.apache.org/  
  
Benchmarking localhost (be patient)
Completed 100 requests  
Completed 200 requests  
Completed 300 requests  
Completed 400 requests  
Completed 500 requests  
Completed 600 requests  
Completed 700 requests  
Completed 800 requests  
Completed 900 requests  
Finished 1000 requests  
Server Software:        Apache/1.3.26  
Server Hostname:        localhost  
Server Port:            80  
  
Document Path:          /dummy.dat  
Document Length:        1048576 bytes  
  
Concurrency Level:      20  
Time taken for tests:   23.763 seconds  
Complete requests:      1000  
Failed requests:        0  
Broken pipe errors:     0  
Total transferred:      1049356904 bytes  
HTML transferred:       1049083631 bytes  
Requests per second:    42.08 [#/sec] (mean)
Time per request:       475.26 [ms] (mean)
Time per request:       23.76 [ms] (mean, across all concurrent requests)
Transfer rate:          44159.28 [Kbytes/sec] received  
  
Connnection Times (ms)
              min  mean[+/-sd] median   max  
Connect:        1    21   13.6     20   123  
Processing:   279   454   81.0    432   919  
Waiting:      275   452   81.0    430   916  
Total:        279   475   82.6    448   930  
  
Percentage of the requests served within a certain time (ms)
  50%    448  
  66%    454  
  75%    464  
  80%    477  
  90%    482  
  95%    649  
  98%    745  
  99%    929  
 100%    930 (last request)

一方、tomcat では十分最適化をかけた後でもこのくらい。

kazawa@tpx20:~$ ab -c 20 -n 1000 http://localhost:8080/dummy.dat  
This is ApacheBench, Version 1.3d <$Revision: 1.65 $> apache-1.3  
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/  
Copyright (c) 1998-2002 The Apache Software Foundation, http://www.apache.org/  
  
Benchmarking localhost (be patient)
Completed 100 requests  
Completed 200 requests  
Completed 300 requests  
Completed 400 requests  
Completed 500 requests  
Completed 600 requests  
Completed 700 requests  
Completed 800 requests  
Completed 900 requests  
Finished 1000 requests  
Server Software:        Apache-Coyote/1.1  
Server Hostname:        localhost  
Server Port:            8080  
  
Document Path:          /dummy.dat  
Document Length:        1048576 bytes  
  
Concurrency Level:      20  
Time taken for tests:   39.073 seconds  
Complete requests:      1000  
Failed requests:        0  
Broken pipe errors:     0  
Total transferred:      1055016112 bytes  
HTML transferred:       1054807228 bytes  
Requests per second:    25.59 [#/sec] (mean)
Time per request:       781.46 [ms] (mean)
Time per request:       39.07 [ms] (mean, across all concurrent requests)
Transfer rate:          27001.15 [Kbytes/sec] received  
  
Connnection Times (ms)
              min  mean[+/-sd] median   max  
Connect:        0     8   14.1      7   299  
Processing:   491   769   79.2    751  1338  
Waiting:      490   765   79.3    747  1335  
Total:        491   777   81.8    758  1340  
  
Percentage of the requests served within a certain time (ms)
  50%    758  
  66%    777  
  75%    783  
  80%    785  
  90%    800  
  95%    826  
  98%   1080  
  99%   1331  
 100%   1340 (last request)

localhost でテストしているのでボトルネックはローカルの CPU か IO、1Mbytes のファイル一つなら完全にキャッシュに乗っかってしまうことを考えるとたぶん CPU にあるわけですが、apache へのテスト実行時、CPU はほとんど system に費やされているのに対し、tomcat では user と system が半々ぐらいとなっており、このあたり (対 kernel で見た時の apache の皮の薄さに対して JavaVM の厚化粧っぷり) が原因かも。このくらいの規模のテストだと、マシンリソースへの要求はやっぱり tomcat の方がかなり大きいですからね…¹。

apache2 ではまだテストしてません。また後程。

apache2

というわけで、apache 2.0.49 でも試してみました。prefork MPM では面白くないので、worker MPM を使って見ました。

kazawa@tpx20:~$ ab -c 20 -n 10000 http://localhost:8080/hello.html  
This is ApacheBench, Version 1.3d <$Revision: 1.65 $> apache-1.3  
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/  
Copyright (c) 1998-2002 The Apache Software Foundation, http://www.apache.org/  
  
Benchmarking localhost (be patient)
Completed 1000 requests  
Completed 2000 requests  
Completed 3000 requests  
Completed 4000 requests  
Completed 5000 requests  
Completed 6000 requests  
Completed 7000 requests  
Completed 8000 requests  
Completed 9000 requests  
Finished 10000 requests  
Server Software:        Apache/2.0.49  
Server Hostname:        localhost  
Server Port:            8080  
  
Document Path:          /hello.html  
Document Length:        92 bytes  
  
Concurrency Level:      20  
Time taken for tests:   9.430 seconds  
Complete requests:      10000  
Failed requests:        0  
Broken pipe errors:     0  
Total transferred:      3580000 bytes  
HTML transferred:       920000 bytes  
Requests per second:    1060.45 [#/sec] (mean)
Time per request:       18.86 [ms] (mean)
Time per request:       0.94 [ms] (mean, across all concurrent requests)
Transfer rate:          379.64 [Kbytes/sec] received  
  
Connnection Times (ms)
              min  mean[+/-sd] median   max  
Connect:        0     9    2.9      8    48  
Processing:     7    10    2.2      9    50  
Waiting:        6     9    2.1      8    48  
Total:         17    18    3.3     17    58  
  
Percentage of the requests served within a certain time (ms)
  50%     17  
  66%     18  
  75%     18  
  80%     18  
  90%     20  
  95%     25  
  98%     26  
  99%     27  
 100%     58 (last request)

はやっ！1Mbytes のファイルについても、

kazawa@tpx20:~$ ab -c 20 -n 1000 http://localhost:8080/dummy.dat  
This is ApacheBench, Version 1.3d <$Revision: 1.65 $> apache-1.3  
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/  
Copyright (c) 1998-2002 The Apache Software Foundation, http://www.apache.org/  
  
Benchmarking localhost (be patient)
Completed 100 requests  
Completed 200 requests  
Completed 300 requests  
Completed 400 requests  
Completed 500 requests  
Completed 600 requests  
Completed 700 requests  
Completed 800 requests  
Completed 900 requests  
Finished 1000 requests  
Server Software:        Apache/2.0.49  
Server Hostname:        localhost  
Server Port:            8080  
  
Document Path:          /dummy.dat  
Document Length:        1048576 bytes  
  
Concurrency Level:      20  
Time taken for tests:   7.669 seconds  
Complete requests:      1000  
Failed requests:        0  
Broken pipe errors:     0  
Total transferred:      1048852000 bytes  
HTML transferred:       1048576000 bytes  
Requests per second:    130.40 [#/sec] (mean)
Time per request:       153.38 [ms] (mean)
Time per request:       7.67 [ms] (mean, across all concurrent requests)
Transfer rate:          136765.16 [Kbytes/sec] received  
  
Connnection Times (ms)
              min  mean[+/-sd] median   max  
Connect:        3    11    3.1     12    28  
Processing:   138   140   11.2    138   192  
Waiting:      127   139   11.1    136   190  
Total:        142   152   11.1    149   203  
  
Percentage of the requests served within a certain time (ms)
  50%    149  
  66%    152  
  75%    155  
  80%    156  
  90%    161  
  95%    166  
  98%    198  
  99%    202  
 100%    203 (last request)

と、他を引き離す性能を見せました。正直、1.3 系に対してこれほどアドバンテージがあるとは思いませんでした。それとも 1.3 系も自分でコンパイルしてみたものではまた違うのでしょうか？

なお、性能に関係するパラメータはデフォルトのまま、下記の通りです。

StartServers         2  
MaxClients         150  
MinSpareThreads     25  
MaxSpareThreads     75  
ThreadsPerChild     25  
MaxRequestsPerChild  0  

Kernel 2.6.4 と VMware 4.5.1

VMware の 4.5.1 がリリース、とのニュースを読んで、さっそく入れてみました。
いつも通り tar ball を展開後、vmware-install.pl を実行、4.0.5 の時はひっかかっていた kernel module の作成もさくさく進んで、無事インストール出来たかに見えました。
ところが、いざ実行してみようとすると、Window は表示されるのですが、Guest OS を起動しようとすると signal 11 で落ちてしまいます。/var/log/kern.log には oops まで出てしまう始末。どうも vmmon モジュールがうまく動作していないようです。
しょうがないので 4.0.5 に戻そうとしたんですが、kernel 2.6 に 4.0.5 を入れるための手元にあったパッチ (vmware-any-any-update48.tar.gz) は kernel 2.6.4 の場合は使えず、最新の vmware-any-any-update55.tar.gz もなぜかモジュールコンパイルの途中でエラーが出てうまくいきません。
一瞬途方にくれて「kernel をダウングレードするしかないかなぁ…」と思ったんですが、上記パッチの提供元にあった、obsolete ディレクトリを掘り返してみたところ、vmware-any-any-update53.tar.gz ならば正常にパッチを当てられることが判明、なんとか無事、Kernel 2.6.4 上で VMware を再び動作させることが出来ました。
良かった良かった。