2005/10/23 Sun.
日曜だろうと8時に起きて出勤です。電車が平日と比べて非常に空いているのが救い。天気もいいし、気分は悪くはない。
T野さんが既に更新ファイルをリリースしてくれてたので、アイスコーヒーを買ってきてからテスト開始。午前中に上がりたい。
JSPからシェルを起動する部分があって、シェルから呼ぶJavaアプリでメール送信を行なうはずなのだが、何故か動かん。
今日は本番環境へのリリースなんだけど、開発環境やテスト環境で動かしてみると、メールは正常に送信されている模様。
シェルやJSPなどの各ファイルを見ても他の環境とも差分が無いので、動かないはずはないと思うが。かなり時間を食う。
このシェルの実行ログを「logs」というディレクトリに出力してるんだけど、そのディレクトリが存在しなかったのが原因っぽい。
なるほど、シェルの実行エラーはサーバーログにも出ないし、見つけにくかったワケだ。新規ディレクトリを追加して解決。
とりあえず最低限の動作を確認してから、検査成績書の記述を始める。本番環境で再現できない特殊なケース以外は終了。
自分の作業は比較的早く終わったんだけど、客先の確認が終わるまで帰るワケにもいかず、しょうがなく時間を潰すハメに。
17時くらいになってようやく確認が終わったというので、立川と多摩センをちょっとふらついてから髪を切ろうと思い立つ。
19時まで受付できたと思って18時40分くらいに行ったら、受付時間が変わってて結局髪を切れなかったというオチ付き。
2005/10/24 Mon.
現在開発中のこのシステム、これは海外からも比較的頻繁に使われるようなのだが、どうやら転送量がネックになるらしい。
PDFとかCSVとかじゃなくて、JSPが出力するHTMLに余分な改行やらスペースが多いとの事なのだが、そんなに問題か？
例えば下手にインデントを削ったとしても、保守性と可読性を低下させるのみだし、そもそも数バイトの誤差じゃないんかい。
で、何とか転送量を抑えられないかという話が自分に来た。しかも、向こうの言ってくる内容が基地の外の状態だから困る。
本番環境に適用する時だけ、何かしらのコンバーターを通して改行や余分なスペースを取り払えないかとか言ってるのよ。
当然そんなクソみたいなコンバーターを作るつもりは毛頭ありません。HTTP通信量を圧縮したいなら「GZIP」使うでしょ。
……この説明だけ見ると、ただのファイル圧縮の一環かと勘違いされそうだな。「gzip圧縮転送について」にもリンクを貼るか。
しかしながら、CGIでの使い方なら知っているが、Servletの場合でどうやって使うかがいまいちわからんので調べてみる。
「@IT」の「＠IT 会議室」の過去ログに「HTTP通信データの圧縮」についての話があった。なるほど、サーブレットフィルタね。
「dev2dev Online」ってトコで「GZipFilter」を発見。このアーカイブからjarを取り出し、サーバーのクラスローダーに入れる。
とりあえずは自分のローカルで試験しなきゃいけないので、まずは「Tomcat」のクラスローダーに入れることにする。
続いて、これをサーバーに適用する設定をする必要がある。フィルタやマッピングの設定はweb.xmlに記述することになる。
<filter>
<filter-name>GzipFilter</filter-name>
<filter-class>weblogicx.servlet.gzip.filter.GZIPFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>GzipFilter</filter-name>
<url-pattern>/*.jsp</url-pattern>
</filter-mapping>
この場合、拡張子がJSPの場合のみ圧縮転送を行なう設定となる。画像ファイルも指定できるけど、CPUリソースの無駄。
これで動くとは思うのだが、実際にどれだけのデータがどこまで圧縮できているかが確認する手段が無いので、ログを出す。
「Tomcat」はデフォルトでアクセスログを出してはくれないので、「logs/AccessLog」にログを出すためにserver.xmlを変更。
<Valve className="org.apache.catalina.valves.AccessLogValve"
directory="logs/AccessLog" prefix="tomcat_accs_" suffix=".log"/>
アクセスログの方は、最初からweb.xmlにコメントアウトされた状態で記述されているので、コメントアウトを外すのみでも可。
この修正でアクセスログが出力されるようになり、転送量も同時に記述されるため、圧縮適用時と未適用時で比較可能。
web.xmlの変更適用時と未適用時で転送量を比較した結果、何故か転送量に変化が無い。ってか、圧縮が動いてない？
あれこれ調べてみたんだけど、どうにも正常に動いてくれない。<filter-class>の記述が間違っているとかのミスも無い。
原因不明なので、別のフィルタ使おう。国内サイトには情報が無く、海外の「Coldbeans Software」ってトコで別のを発見。
「Compress Filter」というページにて「gzipflt」ってのがあるので、今度はこれで実験。さて、これで正常に動いてくれるか？
もちろん、web.xmlの修正も必要。jarファイルを解凍して取得できる階層通りに<filter-class>を記述する必要があるので注意。
上の行が非圧縮時、下の行が圧縮時です。各行の一番右端の数値が転送サイズ数。このケースだと、転送量が4分の1に！
これはもしかしたら非常に使えるんじゃないか！？と思ったのもつかの間、圧縮時に出力されたHTMLが何かおかしい。
最後の部分が変なトコで途切れてる！せっかく正常に圧縮フィルタかけられたと思ったのに、またこういう予想外の展開が。
ここまで調査したトコで時間がすでに21時になっていたので、そろそろ帰ることに。明日中には正常に圧縮を動かしたいな。
2005/10/25 Tue.
今日も元気にHTTP圧縮転送を頑張ります。とりあえず、昨日目をつけた「GZipFilter」と「gzipflt」には退場して頂きました。
他に無いかと探していると、「ONJava.com」で「Two Servlet Filters Every Web Application Should Have」ってのを発見。
完全に英語表記のサイトなので頭が痛くなるが、このページからリンクが貼られている「jspbook.jar」を使うことにしてみる。
jarさえ手に入れば、使い方は昨日のモノと同じだし楽勝なはず。正常に動作してくれれば、という条件付ではあるが。
で、早速このjarを使って圧縮転送したところ、昨日の「gzipflt」みたくHTMLが途中で欠けることなく、正常に動きましたとさ。
ここまでやって気付いたんだけど、もしかして昨日使った2つのjarが動かないのって「Tomcat」のバージョンのせいか？
「Tomcat 質問集 - バージョン -」を見ると、使っていた「Tomcat」のバージョン4.1.31ではServlet2.3とJSP1.2対応。
まさかServlet2.4じゃないと動かないjarだったのか？今更気付いたとしても、再検証なんてするワケがないんだけどね。
とにかく、これを開発環境に適用してみたいとこなんだけど、サーバー設定のweb.xmlとか下手に変更したくない部分だな。
明日を一日使って試してみるか。ってか、比較するなら圧縮前のアクセスログも取っておく必要があるか。色々メンドいっての。
2005/10/26 Wed.
web.xmlの変更適用時と未適用時で転送量を比較した結果、何故か転送量に変化が無い。ってか、圧縮が動いてない？
「dev2dev Online」の「GZipFilter」について、一昨日の雑記でこんなことを書いてましたが、どうやら動いていたようです。
何をワケのわからん事を言うのかと思うかもしれませんが、圧縮確認のために用意したテスト用のJSPがちょっとマズかった。
自分は「Tomcat」インストール後にアクセスできるようになる「http://localhost:8080/index.jsp」を試験用のJSPとしていた。
ページを開けばわかると思いますが全て英語で記述されています。言い換えれば、「マルチバイト文字は存在しない」のです。
「jspbook.jar」を使ってgzip圧縮をした際にマルチバイト文字が文字化けすることに気付き、これはまさかとは思ったのだが。
最初はエンコードの関係かと思ってpageEncodingやcharsetでWindows-31Jとかを指定したんだけど、文字化けが直らない。
とりあえず海外で配布されているgzip圧縮のフィルタはマルチバイト文字には対応していないという結論を下しておいた。
では、国内サイトで配布されている「dev2dev Online」の「GZipFilter」をマルチバイト文字のみのページに使ったらどうか？
試験用のJSPとして、改行コード無しで「これはテストです。」と10,000回出力するJSPを作成して、これをgzip圧縮かけてみる。
本来ならば「これはテストです。」の文字列は18バイトで、これが10,000回なので180,000バイトのソースになるはずである。
180,000バイトのソースをブラウザに吐き出すにあたり、サーバー側が転送したデータサイズは何と90,000バイトになった。
「dev2dev Online」の「GZipFilter」はマルチバイト文字のみを検出して、2バイト文字を1バイトに圧縮するフィルタってことか？
この推測が正しいならば、全て半角英数字のみで構成されているページをこのフィルタにかけても変化が無いのは納得。
……ってことは、マルチバイト文字が存在しないページの転送量を軽減するってことは無理なのか？かなり使えないっすよ。
そもそも、海外からアクセスがあった場合に転送量を抑えるのが目的。海外からってことは、ブラウザ言語は英語が主流だ。
ブラウザ言語が英語なら英語ページを出力するように設計しているため、海外からのアクセスでこのフィルタは役に立たない。
海外からブラウザ言語を日本語に設定してアクセスする場合にのみ役に立つフィルタか。ってか、そんなケースあり得ないし。
海外からのアクセスなら「jspbook.jar」で圧縮、国内からは「GZipFilter」で圧縮するように切り分けられれば最高なんだけど。
通常のJavaのソースならともかく、web.xmlでそんな処理の切り分けができるのか？できないだろうなぁ。最善の策は何だ！？
2005/10/27 Thu.
今日も元気にgzip圧縮転送をがんばります。ってか、そろそろ成果の一つも出したいんだけど。流石に時間食いすぎ。
「nami's diary」というblogにてgzip圧縮転送をしているケースが有ったので、とりあえず目を通してからフィルタを取得。
「SourceForge」で公開されているフィルタで、「ehcache-1.1.tgz」と「ehcache-constructs-0.5.tgz」の2つを使うとの事。
で、このフィルタを落としてから気がついたんだけど、「nami's diary」の中で以下の文章が存在する。これは致命的ポイント。
contentTypeのcharsetをWindows-31Jに設定してるんだけど、コンテンツはEUC-JPでエンコードされてしまってるようだ。
JSPのpageディレクティブのcontentTypeのcharsetをEUC-JPに修正したらOKだった。
ってことは、本番に適用するには全ページのcharsetをEUC-JPに修正しないといけない。
冗談じゃありません。ってなワケで、このフィルタは実験するまでも無く却下。出力のエンコードが強制指定なのは頂けない。
ちなみに、先日から実験している「jspbook.jar」のソースが「jspbook.zip」として公開されてるんだけど、結局これもNGだ。
ソースを見ると、出力文字コードがベタ打ちでUTF-8を指定するようになってる。改造するかとか思ったけど、試験がメンドい。
となると、ここまで使ってきたフィルタの中で要求を満たしてくれるようなものが存在しないということになってしまう。
果たしてこの作業が報われるのかどうかが不安になってきたが、夜になって体調不良を感知したので帰ることにするか。
クソみたいな仕様変更の話が来たが、その話を書こうと思ったら段々腹が立ってきたので、途中で止めて書いたのを消した。
2005/10/28 Fri.
∧ ∧ （ ･ω･） ＿| ⊃／(＿＿_ ／ └-(＿＿＿_／ ￣￣￣￣￣￣￣
朝起きる。喉が痛いわ、頭は動かないわで風邪だと断定。来週は死にそうな状況になるので、今週末を使って治そう。
＜⌒／ヽ-、_＿_ ／＜_/＿＿＿＿／
2005/10/29 Sat.
∧ ∧ （ ･ω･） ＿| ⊃／(＿＿_ ／ └-(＿＿＿_／ ￣￣￣￣￣￣￣
昼起きる。喉が痛いのは緩和されたが、今度は体中の関節と筋肉が痛い。特に足。安静を最重視して一日寝て過ごす。
＜⌒／ヽ-、_＿_ ／＜_/＿＿＿＿／