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 のアプリケーションに興味のある方は是非このフレームワークをお試しください。





ちょっと春らしく:




2009年4月27日 at 1:11 AM

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 の画像を使わさせて頂きました。

私が作成した概念図より各スレッド毎に分割されて処理しているのが

分かりやすいので、二つの資料を両方つかうとわかりやすいですね。


2009年4月24日 at 1:03 AM

プロジェクト 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 を有効活用してください。


2009年4月23日 at 10:00 PM

神宮上空のヘリ3台



今日は、神宮のオフィスに出社しているのですが、

昼食時に、ヘリコプターが3台程上空で旋回してました。

何事か?また事件でもあったのか?と思っていたら、

午前中にニュースにあった芸能人さんが原宿署に移送

されたんですね。



この前の爆発もすぐ近くで発生したし、用賀に比べ

この辺りは色々とあるんですねぇ。。。


2009年4月22日 at 10:53 PM

Sun Fire 2270(Intel チップ)で今までの2倍以上のパフォーマンス



Sun Fire X2270Sun 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については過去のエントリで紹介していますので、御参考ください。


2009年4月21日 at 7:33 PM

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億ドルで買収



すいません、社員なので公にコメントしたくてもできないので、

本エントリに関してのみ、コメント欄も無効にさせていただいています。


2009年4月20日 at 6:26 AM

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 のクラスタと負荷分散構成

2009年4月20日 at 2:04 AM

過去の投稿


Java Champion & Evangelist

ご注意

このエントリは個人の見解であり、所属する会社の公式見解ではありません

カレンダー

2009年4月
« 3月   5月 »
 12345
6789101112
13141516171819
20212223242526
27282930  

カテゴリー

Twitter

  • DEISは分かりやすく言うと、HerokuがAzureにやってきた!!という感じかな。 17 hours ago
  • まだ、完全ではありませんが、最初の大事な部分はまとめたので、オリジナルメモよりもやりやすくなるかと思います。 ちなみに、オリジナルの検証メモはこちら。 github.com/yoshioterada/P… 18 hours ago
  • de:code 発表用に DEIS on Kubernetes on Azure Container Service について色々と検証した内容を誰でも触れるように、この土日でハンズオン資料としてまとめました。 github.com/yoshioterada/D… 18 hours ago
  • @opendeis Now, I’m creating following documents. github.com/yoshioterada/D… 1 day ago
  • RT @msdevjp: ジャパン・インターカルチュラル・コンサルティング社 社長 Rochelle Kopp 氏と米マイクロソフト DevOps エバンジェリスト 牛尾 は、DevOpsなどが日本に導入できない理由を、これらが西洋の問題を解決するためのものだからだと指摘。 #… 2 days ago

clustermap

ブログ統計情報

  • 955,338 hits

Feeds