Archive for 4月, 2009
Atmosphere 0.1 GA リリース
Grizzly プロジェクトより派生した Atmosphere プロジェクトの
初めての成果物 (0.1 GA) がリリースされました。
Atmosphere プロジェクトでは汎用的に使える Comet フレームワークとして
AtmosphereHandler インタフェースを実装して簡単に Comet アプリケーションを
作成することができるようになります。
チャットの実装例
今までは Comet のアプリケーションを作成する場合、サーバ側の実装は
各 Web コンテナの Comet Engine の実装に応じてばらばらに実装しなければ
なりませんでしたが、このフレームワークを利用することで、一度実装した
Comet のサーバ側の実装を様々な Web コンテナ上で動作させることができるようになります。
サポートされる Web コンテナ:
Tomcat,Jetty, GlassFish,Weblogic, Jersey,Grizzly
チャットアプリケーションの実装例:
Getting started with Atmosphere CPR part 1: Writing the HelloWord of Comet….a Chat application
Comet のアプリケーションに興味のある方は是非このフレームワークをお試しください。
ちょっと春らしく:
Blocking I/OとNon Blocking I/Oについて
以前、Grizzlyの概要 : C10K問題に対応するGlassFish(Grizzly) というエントリで、
Grizzly が実装している Non Blocking I/O の利点について説明しましたが、
Project Kenai 中のプロジェクト Grizzly-send file 内で過去に書いたエントリの
補足となるような良い説明資料があがっていましたので、こちらでも紹介します。
※ このエントリを読む前に是非、過去の記事をご覧ください。
マルチスレッドで実装された Webサーバ は下記のようにAcceptor スレッドとWorker スレッドの間に
Queueを置いて、処理の効率化をはかっています。
この時、仮に Worker スレッドの数が5個だった場合に8クライアントから同時にファイル取得の
要求が来た場合を想定します。
Blocking I/Oを使って実装されたマルチスレッドサーバの場合、実際に作業ができるWorker スレッドは
5つしかありませんので、3つのクライアントは他の処理が終わるまで Queue で待たなければなりません。
取得する対象のコンテンツサイズが小さい、もしくはすぐに完了するような場合、このBlocking I/O
のマルチスレッドサーバは高速に動作します。
しかし、クライアントからのリクエスト数が膨大になった場合や、取得するコンテンツのサイズが大きい場合、
もしくはコンテンツの取得に時間がかかるような場合、他のクライアントの要求に対して影響が大きいことが
わかります。
一方、Grizzly のように Non Blocking I/O に対応した Web Server を利用すると、Woker スレッドを
効率的に利用することができるようになります。
5つの Woker スレッドが8クライアントからの同時アクセスに対して、各スレッド毎で分割して
処理できますので、誰か1人が大きなファイルを取得したとしても他の人に対して影響は少なく
なります。
そこで、クライアントからのリクエスト数が増えれば増える程、Non Blocking I/Oの実装の恩恵を
受ける事ができます。
PS.
今回は Project Kenai の Grizzly-Send file の画像を使わさせて頂きました。
私が作成した概念図より各スレッド毎に分割されて処理しているのが
分かりやすいので、二つの資料を両方つかうとわかりやすいですね。
プロジェクト Kenai について
Project Kenai
オープンソースのプロジェクトを立ち上げたい方
いらっしゃいますか?
自分でプロジェクトを立ち上げた場合、色々な
環境を構築したり管理をしたりしなければなりません。
そのようなオープンソースのプロジェクトを立ち上げるに
あたり必要なリソースを全て利用できるのが、Project Kenaiです。
Project Kenai では下記のようなリソースを提供しています。
● ソースコードの管理(Subversion, Mercurial等)
● 問題追跡(Jira, Bugzilla等)
● Wiki
● フォーラム
● メーリングリスト
● ドキュメントの公開
● NetBeansとの統合
このようなリソースをいちいち自分で管理しなくてもよくなるので、
OSSプロジェクトを立ち上げたい方にはとても便利だと思います。
既存のプロジェクトに参加する場合は、サインアップするだけで利用可能です。
また、新しいプロジェクトを立ち上げたい場合はリクエスト
を提出し承認されると利用できるようになります。
※ すでに、US の Sun Developer Network のメンバー登録を行って頂いている方は、
その ID でログインできます。
参考情報:
Project Kenaiについて
NetBeans との統合について
Project Kenai のブログ
Project Kenai Twitter
Project Kenai Facebook
例えば、Grizzly の sendfile の実装もこの Project Kenai の配下で
行われています。
是非、この Project Kenai を有効活用してください。
神宮上空のヘリ3台
今日は、神宮のオフィスに出社しているのですが、
昼食時に、ヘリコプターが3台程上空で旋回してました。
何事か?また事件でもあったのか?と思っていたら、
午前中にニュースにあった芸能人さんが原宿署に移送
されたんですね。
この前の爆発もすぐ近くで発生したし、用賀に比べ
この辺りは色々とあるんですねぇ。。。
Sun Fire 2270(Intel チップ)で今までの2倍以上のパフォーマンス
Sun Fire X2270 と Sun FIre 4170 の Intel チップを搭載したH/Wで GlassFish v2.1 と MySQL の
ベンチマークを計測した結果 (2925.18 JOPS) が SPECjAppServer2004 に公開されました。
SPECjAppServer®2004
Sun GlassFish Enterprise Server v2.1 on Sun Fire X2270 with MySQL 5.1 on OpenSolaris 2008.11
これによると、2008年に実施した Sun Fire X4150 の結果 (1,197.10 JOPS)と比べ2倍以上の
結果が得られています。
ベンチマークのシステム構成:
また、先日 GlassFish のハイパフォーマンスを底辺でささえる、Grizzly の新版である Grizzly 2.0.0
マイルストーン1もリリースされたようです。
http://weblogs.java.net/blog/jfarcand/archive/2009/04/grizzly_200m1_r.html
http://blogs.sun.com/oleksiys/entry/grizzly_2_0_m1_release
Grizzly 2.0M1の入手
Grizzly 2.0M1のJavaDoc
Grizzlyについては過去のエントリで紹介していますので、御参考ください。
Sun と Oracle について
続々とニュースが出てきていますね。
http://www.sun.com/third-party/global/oracle/
http://www.oracle.com/sun
IT media:Oracle、Sunを買収
CNET Japan: オラクル、サンの買収で最終合意
マイコミジャーナル:【速報】米Oracle、Sun Microsystemsを56億ドルで買収
slashdot: Oracle、Sunを74億ドルで買収
すいません、社員なので公にコメントしたくてもできないので、
本エントリに関してのみ、コメント欄も無効にさせていただいています。
GlassFish と Tomcat の違い Part 4
GlassFish と Tomcat の比較について何度か説明してきていますが、
(過去記事)
実際のところ、GlassFish は Tomcat より何が便利なのでしょうか?
今日は、Tomcat ユーザがかかえる問題である「管理の手間について」
管理作業を軽減するために、GlassFish の便利な管理機能について紹介します。
さて、皆様、まず Tomcat でシステムを構築したとしましょう。
この時、サービスが構築時に予想した範囲のアクセス数、処理数で
十分な場合は何も問題がありませんが、サービスが成長してきて
1台のマシンでは処理を裁ききれなくなった場合はどのようにして
システムを拡張していますか?
Tomcat を利用している方は、1台づつマシンにインストールして
1台づつ ログインしては設定を行っていると思います。
設定変更がさほどない環境であればこれでも我慢ができるかもしれません。
しかし、アプリケーションの開発において DB のリソースを追加したいことや、
新しいアプリケーションを追加したい場合も多々あるでしょう。
そのような時、Tomcat では毎回1台づつログインして設定を変更しなければ
なりませんでした。
同じ設定を行うのに1台づつログインして設定して再起動してというような
作業は面倒ではありませんか?
また、作業の数が増えれば増える程、XML ファイルの設定ミス等が発生します。
設定ミス等でアプリケーションが正常に起動しないなんてことで困ったことはありませんか?
GlassFish を利用するとこのような手間と設定ミスのリスクを大幅に軽減してくれます。
インストールは各マシンに行っていただく必要がありますが、リソースの追加や設定変更、
アプリケーションサーバの再起動のために、毎回各システムに対してログインをしなくても済みます。
GlassFish では “ドメイン管理サーバ”(DAS)と呼ばれる1つのアプリケーションから
全てのアプリケーションサーバの設定、たとえばリソースの追加や、起動、停止、
配備、配備取り消し等の操作を行うことができるようになるでしょう。
また、クラスタというアプリケーションサーバのインスタンスの共通グループを
作成する事で、同一クラスタ(グループ)に所属する全てのインスタンスに対して
同一の設定を行いたい場合、たった1回の操作で全てのインスタンスに対して
同じ設定を行うこともできるようになります。
これにより、XMLの編集ミスといった初歩的なミスを大幅に軽減することが
できるようになり、サービスの成長に伴い台数がいくら増えても管理の手間は
増えず、管理時間も大幅に軽減されるようになります。
Tomcat ユーザの皆様?
1台づつログインして設定して、設定をコピー&ペーストして面倒ではありませんか?
中規模から大規模なサービスを展開する場合、この GlassFish が持つ管理機能はとても
便利です。Tomcat の管理で面倒だと感じている管理者の皆様、是非一度
GlassFish を触ってみてください。
設定方法に関する参考資料:
GlassFish のクラスタと負荷分散構成
JavaSE6 と GlassFish で JSP の高速コンパイル
皆様、JSR-199 (Java Compiler API)をご存知でしょうか?
Java SE 6 で拡張された機能の一つなのですが、この API を
利用すると、Java のプログラム中から Java のソースコードを
コンパイルできるようになります。
一見すると、この機能と GlassFish どのような関連があるの?
と思われる方もいらっしゃるかと思いますが、JSR-199 に対応した
JSP コンパイラが GlassFish 上で実装されています。
そこで、JSP/JSF 等のコンパイルが非常に高速になります。
(一説によると3.5倍〜10倍早いとか)
今までは、JSP をコンパイルした後、Servletコードをファイルに
出力してロードしてとアプリケーションの起動までに結構時間が掛かった
りしましたが、GlassFish ではファイルに書き出さず直接メモり上で
コンパイル等の動作を行うことができます。
ですので、
GlassFish は Java SE 6 で動かすことをおすすめ致します。Java SE 5 を
ご使用中の方は、バージョンを変更したい場合、下記のファイルを修正し
変更してください。
# vi glassfish-v2.1/config/asenv.conf AS_JAVA=”/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home” |
また、開発者の方は、上の説明でではコンパイルされたコードを
見たい場合はどうすればいいのだろう?と思う方もいらっしゃると思います。
NetBeans をご使用されている方は、Web のプロジェクトを作成した際に
デフォルトでソースコードが出力される設定が追加されています。
具体的には、プロジェクト中の設定ファイル(sun-web.xml) に
下記の行が追加されています。
<jsp-config> <property name=”keepgenerated” value=”true”> <description>Keep a copy of the generated servlet class’ java code.</description> </property> </jsp-config> |
開発者の方はこれを消していただくことで、Java のコードは出力されなくなり
全てメモり上で作業が行われますので下記を消して再度配備してみてください。
逆に言うならば、NetBeans 等をご利用されていない場合は、上記のコードを
記載していない場合、Java のコードは出力されませんのでご注意ください。
ちなみに、Java のソースコードの出力先は下記になります。
glassfish-v2.1/domains/domain2/generated/jsp/j2ee-modules/APPLI_NAME/org/apache/jsp |
効果の程は、是非皆様ご自身の手で試してみてください。
参考資料の抜粋:
◎
http://blogs.sun.com/kchung/entry/speed_up_jsp_compilations_with
The performance gain for using JSR1 199 API is amazing! Preliminary measurement shows an order of magnitude improvement in raw Javac compilation speed, and a 3.5X improvement in overall execution when running JSP TCK tests! |
◎
https://glassfish.dev.java.net/ja/public/WP_GlassFish_Overview.pdf
GlassFish のもう 1 つの注目すべき変更点は、Java コンパイラの Jasper が Java SE 6 のコンパイラ API (JSR-199) を利用できるようになり、ファイル IO の回避とコンパ イル速度の大幅な向上 (非公式の計測では約 10 倍の高速化) が実現されたことで す。JSR-199 を使用する場合ほど高速ではありませんが、Eclipse JDT コンパイラを 使用するように Jasper を構成することもできます。残念なことに今は手元にベン チマーク結果がないのですが、JSF 実装も大幅に改善されました。 |
GlassFish v3 のスケジュール公開
GlassFish v3 のスケジュールがドラフトとして公開されたようです。
GlassFish v3 リリーススケジュール
ここ最近の私のプレゼンを聞いてくださった方にはリリースが遅れるかもしれない
ことを伝えておりましたが、上記でスケジュールドラフトが公開されたようです。
当初、GlassFish v3 は今年の JavaOne でリリース予定でした。
しかし Java EE 6 の仕様策定が今年までずれ込んだため
(本来は仕様は昨年末に FIX 予定でした)
Java EE 6 の参照実装である GlassFish v3 の開発スケジュールもリスケされ、
結果として今年の秋のリリースとなる予定です。
GlassFish v3.0 は Java EE 6 の参照実装を公開するという意味合いが強く、
エンタープライズ環境で必要なクラスタなどの管理機能が
含まれていません。
そこで、GlassFish v3.0 は開発者の皆様が Java EE 6 の開発に
なじんで頂くための製品としてとらえて頂ければと思います。
エンタープライズ環境でクラスタ等の機能が利用できるように
なるのは GlassFish v3.1 になってからになります。
GlassFish v3.1 のリリースは恐らく2010年以降になるかと思いますので
それまでは、現在の GlassFish v2.1 を本番環境でご使用頂ければと思います。
また、既存の GlassFish v2 のユーザには一つだけ残念なお知らせがあります。
GlassFish v3 は新しいアーキテクチャ(OSGi対応)となるために、
既存の GlassFish v2.x ユーザはアップグレード時に少しだけ
手間を掛けていただく必要があります。(2009年4月時点の方針)
今まで、Sun のアプリケーションサーバ (Sun Java System Application Server )を
使って頂いていた方は、GlassFish Enterprise Server のインストール時に既存の
インストールパスを指定すれば既存の、アプリケーションや設定等をそのまま自動的に
アップグレードしGlassFish 環境で動作させることが可能でしたが、GlassFish v2 から
GlassFish v3へはインストール時にそのような自動アップグレード機能が存在しません。
GlassFish v2 から GlassFish v3 へは手動で設定してアップデートしていただくか、
もしくはかんたんにアップデートできるようなツールが用意されるかと思いますが、
今までよりもインストール時のアップグレードに対して若干手間が掛かってしまいます。
アーキテクチャの大幅な変更のため、どうぞご理解頂ければと思います。
(まだ、開発中の製品ですので今後方針が変わる可能性もあります。
また、もちろん新規構築のシステムであればインストールや導入も非常にかんたんです。)
しかし、そのような手間が掛かったとしても、GlassFish v3 になると OSGi 対応、
モジュール化の恩恵が多いに受けられると思いますので、どうぞ楽しみにしてください。
GlassFish v3 は Java EE 6 の参照実装として位置づけられた製品ですが、
Java EE を動かすためだけのサーバではありません。
JRuby がネィティブで動作したり、EJB が必要なければ使わなくてもすむというような
ユーザのニーズに柔軟にこたえることができる、サーバに生まれ変わります。
(起動時間もたった数秒です。)
今まで、アプリケーションサーバは重たいし EJB が必要ないから Tomcat で十分と
思っていらっしゃる方も多いかと思います。
GlassFish v3 はアプリケーションサーバの常識が変わります。
是非、GlassFish v3 に期待していてください。