朝びらき丸を観に豊洲2月はなんか忙しかったし、3月は計画停電とか節電でどうにも身動きが取れなかったけど、桜にも葉っぱが出てきたことだし、ということで、子供とナルニアを観に行くかとなった。なったは良いが、どこもやってないじゃん。とっくに3D上映館はガリバーや気の早いところはラブンツェルになっている。探しに探して豊洲でやっていることを見つけて行ってきた。なんかこないだ、国際展示場から歩いて帰るときに通ったあたりだなぁと思ったが、それはそれとして、中に入ったら、都内のそれも銀座から数キロ(歩いて余裕で行ける距離だというのは体験済み)のところに、あんなばかでかいショッピングモールがあるのにはたまげた。事前に駐車場は4000台収容(その時点でばかでかいのだろうとは想像はしていたが)と書いてあるので当然車で行こうと思ったが、もし満車だったら映画の時間に間に合わない(インターネットで予約販売ができるのであらかじめ買ったのであった)のでちょっと悩んでいたが、土地勘がありそうなmatarilloさんに訊いたらキッザニアは混んでいるけど(実際にはこれも節電とかの影響かも知れないがそんなには混んでい無そうだったし、外から眺めてもなんだかよくわからない不思議な施設だな)満車で入れないってことは無いよと教えてもらえて、実際にするっと入れた。ショッピングモール(真ん中は吹き抜けで両側に細かい店があるやつ)で、おお、ショッピングモールですなぁと少し感心しながら、飯食ったり本屋(でっかな紀伊国屋が入っている)をぶらぶらしたりしながら、観て来たのであった。予告編でパイレーツオブカリビアンをやっていて、なんだか3Dというよりも飛び出す絵本のような2次元の板を並べたような不思議な感じで、もしかして実写の3Dってこんな気持ちの悪いやつになるのか、とちょっと慄いたが(ナルニアも実写3Dなわけだし)、本編はそんなことはなくて良い感じだった。お話は、ナルニアだから説教臭いところはあるのだが、テンポは良いし、キャピバラみたいにどでかいネズミのリーピチープは相変わらず良い演技だしおもしろかった。いうよりも唐突に出てくるドラゴンの使い方は実にうまい(子供の頃読んだのだが、ああそういえばそうだったときちんと思い出したのはかさぶたをライオンが剥がす砂浜のシーンからだ)。・一本足のセリフの最後のパートが、棒読みのイェーイ(家庭内流行語となった)・ユースティスのオールが丸わかり(で、おもしろい)・英国王のスピーチ重要ラストは思わず目に涙(子供が映画館を出てからもしゃくりあげているのにはちょっと閉口したけど)。映画としてのできは3作目がいちばんかも知れないな。貞次)(で、原作はほとんど覚えていないのだが、エンディングロールにオリジナルの挿絵を使っていて、それを観ると、ユースティスとエドマンドの金髪/黒髪が逆転しているらしくて(おれは縄にぶら下がっている画のところで、あれっと思ったが、子供はもう少し前に気付いたみたいだ)そこがちょっとおもしろい)ただ、邦題は、どうにも好きになれないリュリの曲の名前みたいで今八くらいだ。原訳題のほうが良いと思うのだがな(事前調査で~丸という名前のウケが悪かったから変えたというような記事だかPRだかを読んだので、そういうものかも知れないが)。演能の続き考えてみたら、特にアプリケーションを作らなくても、Railsにindex.htmlを返させるだけでもWEBrickとの比較はできるのだから、JMeter使っていろいろ試してみた。・500になりまくる→JMeterが受信完了時あるいはタイムアウト時にコネクションを切るとERROR_CONNECTION_INVALIDが返るのだがそれを考慮していなかった→レスポンスボディの送信後であれば無視するように修正。・終結方法がかっこ悪い→waitでEINTRを見るのように修正→EINTRを先に見られると拾えない→shutdownメソッドで終了フラグを立ててwait前にチェックするように修正。・WEBrickは作ったスレッドすべての終結をチェック(真似する)→TODO・ThreadErrorになることがある(ある程度まではスレッドプールを実装すれば回避できるはず)→TODO・Railsがキャッシュ関係のNoMethodErrorを出すことがある(出ないときが多い。例外をスローすると出やすい感じだがERROR_CONNECTION_INVALIDを直したらほとんど出ることがなくなった)→TODO(再現したら調べる)という感じ。100スレッド100回実行(=10000リクエスト)のrailsのindex.htmlを返すだけのシンプルなテストをMBPから実行すると(最初、Rackのデフォルトポートの9292が内部ファイアウォールで遮断されていることに気づかず、なぜ受信しないのかとまどった)、90%Lineが164msec、Throughputが643.3/secとなった。200スレッド100回実行(=20000リクエスト)では90%Lineが359、Throughputが616.3/sec。(そもそもMBPから200スレッド本当に同時に動かせているのかは怪しい気もするけど)同じ100スレッドをWEBrickに適用するとエラーになりまくる。ResponseTimeoutが短すぎてTimeoutになっているからだと気づき(1秒に設定していた)、受信タイムアウトを10秒に変えて(接続タイムアウトは100ミリ秒)みると、90%が4558、Throughputが23.1/secとなった。200スレッドのテストはやる必要もなさそうだ(Mongrelと比較しないと意味ないかも)100スレッドのテストでは約28倍のスループットということになる。これだけ違うのなら、まだ実装していないUnknownヘッダ変数関係の処理を入れても問題なさそうだ。(実際のアプリケーションだと、スレッド切り替えのタイミングがアプリケーションに相当依存するはずだから、もっと差は縮まる可能性は高いがやってみなければわからない。