トップ > gae

DI コンテナの起動が遅いなら、起動が速いのを作ればいいじゃない

gae java

自分で書いたコメントなんだけど、今見るといいこと書いてあるように思うので、エントリにしてみる。3行でまとめると：

  • Spring の起動が遅いことと、DI コンテナの起動が遅い/速いというのは、別の話。
  • DI コンテナの起動が遅いなら、起動の速い DI コンテナを作ればいいだけであり、あれだけ推していたものを起動の遅さを理由に使わないのはおかしい。
  • DI の有用性は、App Engine に関係しない。App Engine で必要ないなら一般のアプリでも必要ないはず (でもそうじゃないよね)。

> DIを使うとspin-upが遅くなってしまうから使わない方が良いみたいです。Springとかはそれでかなり苦労してるらしいです。

うーん、どうでしょう？
「Spring の起動が遅い」ことと「DI コンテナの起動が遅い」ことは別の話ですよね？spin up time が問題なら起動の速い DI コンテナを作ればいいのであって、DI コンテナを捨てるのは間違った選択じゃないでしょうか。従来の DI コンテナが起動時にすべてのクラスをロードするようなアーキテクチャだから起動が遅いのだと推測しますが、だったらロードを遅延させるような DI コンテナを作ればいいだけの話です (ひがさんの実力なら難しいことでもないでしょう)。
少なくともあれだけ「DI はスバラシイ」と主張していた陣営が、こんなことを理由にあっさりと DI コンテナを捨てるというのは、なんというか不自然さを感じます。

> おそらくひがさんは、DIを使うメリットがなくて、それよりもデメリットの方が大きくなる(spin upの時間はとても大切)から「複雑になるだけ」という言い回しになったんじゃないかーと思います。

DI コンテナ導入の具体的なデメリットが spin up time のことしか言及されてないのですが、仮にデメリットがその点だとしても、それを「複雑になる」という表現はしないと思います。だから spin up time の問題とは別に、DI コンテナの導入が「複雑」だと表現したのだと思います。

> 実際使ってみるとappengine上でDIが必要になったケースは(自分で使ってる限りでは)ないですね。

なぜ App Engine だと DI コンテナを必要としないのか、その理由はぜひ知りたいですね。ひがさんが述べているように、テストのしやすさとトランザクションまわりが他の手段で代替できるからというのが理由なら、別に App Engine に限った話じゃないと思います。

まつもとさんも「DI コンテナは必要ない」と主張しているんですけど、それは Ruby のような動的な言語に限定した話であって、Java のような融通の利かない言語では DI なり AOP なりで柔軟性を持たせる必要があると思います。App Engine に関係なく。

2010-04-20 - kなんとかの日記

＃しかしそこまでして Java にこだわるかね。spin up time でさんざん苦労するなら、Python 覚えた方がはやくね？

App Engine で DI を使うメリットはない？

gae java

DIの主なメリットは、テストのしやすさと宣言的トランザクションだと思いますが、AppEngineではモックなしで簡単にテストができ、Bigtableの仕様的に宣言的トランザクションはほとんど使えないので、AppEngineでDIを使うメリットは余りないんじゃないかと思います。単に複雑になるだけ。

これが、Slim3でDIをはずした理由です。

2009-11-15 - yvsu pron. yas

うーん、どうだろ。DI のメリットって、システムを疎結合にできることだと思うんだけど。疎結合にできるから、たとえばテストがしやすくなったりするわけで。疎結合にできるメリットは App Engine でもうれしいと思うけど、違うのかな。なんか他の意図があるような気もする。

それより、『単に複雑になるだけ』という言葉が気になる。やはり Java 屋さんにとっても、DI コンテナを使うのは複雑さが増すという認識なんですかね。『DI は簡単だ』という人もいれば『複雑だ』という人もいて、どちらも都合のいいときに都合のいい主張をしているだけのように見える。

あと『AppEngine』が正しいのか、それとも『App Engine』が正しいのか、非常に気になるんですけど、実際どっちが正しいんでしょうか。2ch のスレが『AppEngine』と『App Engine』とで分かれてて混乱するわ。

Google App Engine で Java を使うと起動時間が数秒もかかるらしい

gae java

　上記3つの対策を施し、詳細は省略しますが約50回の起動で、最小3693ms、最大14303ms、平均6884msとなりました。対策前（平均8895ms）と比較すると2000ms程度の改善です

GAE/J、起動時間（spin up時間）短縮の試行錯誤 : CB NANASHI管理人ブログ

これ、まじなのか。『平均6884ms』って、つまり起動に6.8秒もかかるってことだよね。

Google App Engine で Java を使うと、起動するのに平均で約7秒、最大で14秒もかかるのか。これはひどい。

この上でさらに JRuby + Rails を動かしてる人たちはすごいな。尊敬はするけど、真似しようという気にはならない。


ところで実際にサイトにアクセスしてみたが、数秒も待たされることは全然なくて、さくさく表示された。比較的アクセスがあるサイトなら、起動時間はあまり考えなくてもいいということかな。

Google App Engine ではプログラムから static ファイルを読みこめない

gae python

Google App Engine で、スクリプトから画像ファイルの一覧を取り出そうとしたけど、できなくてはまった。

helloworld.py

# -*- coding: utf-8 -*-
import os, glob
print "Content-Type: text/plain"
print ""
print "hello"
imgdir = os.path.join(os.path.dirname(__file__), 'img')
for x in glob.glob(imgdir + '/*'):
    print x     #=> 何も表示されない

print open(imgdir + '/favicon.ico')
   #=> IOError: [Errno 13] file not accessible

ドキュメントによれば、ファイルへの書き込みはできなくても読み込みはできるはずなんだけど。

アプリケーションは、ファイル システムへの書き込みはできません。ファイルの読み取りはできますが、アプリケーション コードとともにアップロードされたファイルのみに限られます。

http://code.google.com/intl/ja/appengine/docs/whatisgoogleappengine.html

と思ってたら、こんな投稿が。

You can read files that weren't marked as static resources, in the regular fashion.

Google グループ

どうも、static ファイルとして設定したファイルは、スクリプトから読み出せないようだ。

application: helloworld
version: 1
runtime: python
api_version: 1

handlers:
  - url: /css
    static_dir: css
  - url: /js
    static_dir: js
  - url: /img
    static_dir: img     # 'img' 以下は static ファイルとして指定
  - url: /.*
    script: helloworld.py

つまり、static ファイルとそうでないファイルとでは、そもそもファイルの配置場所が違うんだろうな。だからスクリプトからは static ファイルが簡単には読み出せないんだろう。


ところでこの制限は公式のドキュメントに書かれてあるんだろうか。ご存知の方がいましたら教えてください。