DIとSeasar2の話 - 都元ダイスケ IT-PRESS
を色々書きました。わかりやすいと反響を頂き、喜んでいますｗ ポリモーフィズムの例をもうちっと実用的に書いてみた。 - 都元ダイスケ IT-PRESS DIのお話を書いてみる。 - 都元ダイスケ IT-PRESS http://d.hatena.ne.jp/daisuke-m/20080511/1210485490 さらにSeasar2を味わいまくってみる。 - 都元ダイスケ IT-PRESS 個人的には「Springや他のコンテナで書いたらどうなるのか？」って結構興味があったりします。その昔、本を読んでみて、その感覚で「あ、おれはSeasar2が好き」と感じたまま、S2一辺倒で来てしまったもんでｗ 正直「Springの思想・良いところ」というのが把握しきれていないんだな、ぶっちゃけ（汗 見ての通り、自分は完全にS2寄りなんですが、あらためてSpringの考え方も見てみたいな、と思うのですが
ベンチマークを更新しました - あるまに
SpringFramework 2.0.4で、ちょうどベンチマークに関係する部分のパフォーマンスチューニングを行ったとの事なので（詳しくは次のエントリ参照）、再度ベンチマークを行いました。Seasar2も最新版に入れ替えた上で、セットアップ処理コードを一部変更しています。 計測内容 バージョンは、Spring 2.0.4 / Guice 1.0 / Seasar2 2.4.12 インスタンス取得はAOP有りとAOP無しの両方を計測（前回は有りのみでしたが、今回は無しも計測しました） 全てプロトタイプ（毎回新しいインスタンスを取得） 取得したインスタンスの実行時間は、AOP有りのみ計測（AOP無しは変わらないはずなので） 留意して欲しい事項は前回の前置きにあります ベンチマーク結果 - get instance (NO AOP)- Spring: 24,336 creations/s Gui
負荷テスト結果 - 設計と実装の狭間で。
ここから先が数字です。 補足や雑感をダラダラ書いたりもしています。 Requests per secondの数字は大きい方が、スループットが高く、より速いという事になります。 又、No.は、補足説明をする際に使用する項番です。 尚、スクリプトを見れば分るとおり、5回に渡って負荷をかけています。 それぞれの結果の中から、最も端的に結果を確認できる「Requests per second」を一覧化してみました。 No. (1) Struts + S2.4 + Kuina-Dao + JPA(Hibernate) 1075.44 [#/sec] 1107.79 [#/sec] 1105.82 [#/sec] 1108.95 [#/sec] 1188.89 [#/sec] (2) Struts + Spring2 + JPA(Hibernate) 974.94 [#/sec] 980.48 [#/
負荷テストスクリプトについて。 - 設計と実装の狭間で。
どの様な負荷をかける事によって得られた結果なのかについて、それなりに書いておきます。 負荷テストは、負荷のかけ方によって、180度違った結果が出る事があります。 今回は、Seasar2とSpring2の比較をしていますが、 僕がSeasar2寄りなモノの考え方をしているのは事実であり、その一点のみにおいて、Spring側は不利です。 例えば、Seasar2では、HotDeployと言う、パフォーマンスを犠牲にして開発効率を優先する機能がありますが、 当然の事ながら、この負荷テストを行うにあたって、当該機能はOFFになっています。 又、非常に単純な方法で負荷をかけていますので、現実の案件でやるべき負荷テストとは、 テストとしての品質において非常に劣っていると言わざるをえません。*1 基本的には、これから負荷テスト的な事をやりたいと思っている人の参考に少しでもなれればイイなぁ…と、思います。
負荷テストの環境について。 - 設計と実装の狭間で。
今回の負荷テストを行ったハードウェア及び一部のミドルウェアについてです。 CPU vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Xeon(R) CPU 5160 @ 3.00GHz stepping : 6 cpu MHz : 3000.274 cache size : 4096 KBXeon 3GHz デュアルコアのCPUが2つのってるサーバです。 結局、コアは4個って訳です。 メモリ MemTotal: 2074780 kBんーと、つまり、2GBですな。 OS Linux version 2.6.9-34.ELsmp (bhcompile@hs20-bc1-7.build.redhat.com) (gcc version 3.4.5 20051201 (Red Hat 3.4.5-2))
おおたに6号機の春なりかけ。 - Guice User's Guide
id:iad_otomamayさんがGuiceのユーザーガイドを翻訳（すげーはえー！）してくれてたので、 一覧にしてみた。ありがとうございます、あとでじっくり読ませてもらいます＞id:iad_otomamayさん Guice User's Guide ■Java on Guice ■1. Introduction ■2. Plain Old Factories ■3. Dependency Injection By Hand 続きを読む JavaExpressの後継として、新たにJavaExpertが創刊されます。 このJavaExpertの特集2として、id:yone098さん、id:manholeさんと 一緒にTeedaの入門記事を書かせていただきました。 TeedaCoreから始まり、Extension、Ajaxと全部をまとめて紹介するのはこれが初めてじゃないでしょうか。 もちろんS
(その8) Seasar2をAOPパフォーマンス比較対象に追加 - あるまに
id:koichikさんに「S2も比較に追加して」というコメントを頂いたので、言われた通りの方法で追加して試しました。Seasar2のテストコードはま!さんのSeasar2用コードにkoichikさんの記述を追加しただけのものです。Seasar2は触った事がないのでシングルトンかどうか分からなかったのですが、デバッグしながら見たらinjectされたオブジェクトのIDが呼び出しのたびに異なっていたので、毎回インスタンス化しているのだろう（＝条件は同じだろう）と判断しました。また、上記Springの訂正も含まれています。 最初の3回の結果は以下です。Springにとってはちょっと…. Spring: 1,734 creations/s Guice: 35,161 creations/s S2: 18,395 creations/s Spring: 1,776 creations/s Guice
DIコンテナの設定ファイル書くの？書かないの？
DIコンテナの設定情報，つまり「オブジェクトの依存関係」や「オブジェクトの設定内容」について，規約重視で暗黙のものとするか，ファイルに記述することで形式のものとするかは，個々人によって主張が異なるようである。何が何でも設定ファイルを書かない，あるいは，何が何でも設定ファイルを書く，といった「原理主義者」も多く，多くの場合は彼らの説明に「コンテキスト」が含まれない。よって，主張を聞いても，実際に何らかのDIコンテナを使う際をイメージした場合，その主張に沿う部分と沿わない部分が僕個人の中で発生し，完全に主張を受け入れられないことがよくある。 結局のところ「DIコンテナをどう使うか」（＝上記で言ったコンテキスト）によって，暗黙知とするか形式知とするかを判断しなければならないと思っている。 DIコンテナの適用パターンとして代表的なものは，「View，Business Logic，Dao」といった3
[ThinkIT] 第4回：AOP機能のパフォーマンス比較 (1/4)
今回はAOP処理のパフォーマンスを見ていきましょう。AOPはDIコンテナと一見関係なさそうですが、Seasar2とSpringのどちらのコンテナもAOP機能を提供しています。また実案件でAOP機能を利用しないことはあまり考えられません。 AOPもDIと同様に内部処理が見えづらい処理です。そこでまずAOPについて簡単に解説します。
[ThinkIT] 第3回：DI処理のパフォーマンス比較 (1/4)
<components> <component name="component00000A" class="xxx.Bean00000AImpl" autoBinding="none"> <property name="bean00000B">component00000B</property> </component> <component name="component00000B" class="xxx.Bean00000BImpl" autoBinding="none"/> <component name="component00001A" class="xxx.Bean00001AImpl" autoBinding="none"> <property name="bean00001B">component00001B</property> </component> <compon
[ThinkIT] 第3回：DI処理のパフォーマンス比較 (1/4)
<components> <component name="component00000A" class="xxx.Bean00000AImpl" autoBinding="none"> <property name="bean00000B">component00000B</property> </component> <component name="component00000B" class="xxx.Bean00000BImpl" autoBinding="none"/> <component name="component00001A" class="xxx.Bean00001AImpl" autoBinding="none"> <property name="bean00001B">component00001B</property> </component> <compon
diconファイルの切り替え - ひがやすを技術ブログ
diconファイルのツリーに、以下のインクルード構造が含まれているとします。 someapp/allLogic.dicon <-- someapp/allDao.dicon <-- dao.dicon <-- j2ee.dicon ここで、「テスト時にはj2ee.diconでなくj2ee_test.diconを使いたい」という要請があったとします。 このためには、j2ee.diconの代わりにj2ee_test.diconをインクルードするdao_test.diconが必要です。 さらに、このdao_test.diconをインクルードするsomeapp/allDao_test.diconが必要、…と続きます。 Seasar2.4からは、インクルードするときの条件を指定することができるようになります。そのため、dao.diconで <include condition="テストじゃないとき"
[ThinkIT] 第1回：どっちが速いSeasar2 VS Spring (1/4)
Seasar2が登場して2年が経ち、今では実際の開発でDIxAOPコンテナを使用することは珍しいことではなくなりました。 DIxAOPコンテナを導入するにあたって、他のDIxAOPコンテナとの速度比較やDIxAOPコンテナが行う処理の中でどこに時間がかかっているかについて評価されていることと思いますが、なかなかそのすべてを把握されていないのではないでしょうか。 そこで本連載では、DIxAOPコンテナの生成やコンポーネント取得といったベーシックな機能についてパフォーマンスを測定して、以下にあげた点について明らかにしていきます。 DIxAOPコンテナ（Seasar2、Spring）の実装によって、どれくらいパフォーマンスが異なるのか DIxAOPコンテナが行う処理の中で、どこに時間がかかるのか また結果として速度が遅くなった箇所については、その原因を考察して実案件で役立てていただけましたらと思
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
初心者のための DI 入門 - Aufheben - GLAD!! の日記
Amazon.co.jp: Seasar2で学ぶ DIとAOP アスペクト指向によるJava開発: arton: 本
[ThinkIT] 第2回：init処理とprototype (1/3)
[ThinkIT] 第2回：init処理とprototype (1/3)