※2010/4/23 sessionのクリアについてご指摘頂き、追記しました。Google App Engine for Java(GAE/J)にて、どんなアプリを使う場合でも （自分的に）ほぼ必須となる設定ファイルのまとめ。 ていうか、リファレンス読めばいーんだけどさ １．sessionを有効にする & クリアの設定をする Javaでsession使わないケースなんてあるのか？ appengine-web.xml に 下記を追加 <sessions-enabled>true</sessions-enabled> GAE/Jでsessionを使う場合、このままだとDatastoreにsession情報が残ったままなので定期的にクリアするcronを設定する web.xml に 下記を追加 <servlet> <servlet-name>_ah_sessioncleanup</servlet-
"Google App Engine Java の色々な機能を、実際にコーディングしながら体験してみよう" という主旨のもと、Google App Engine for Java のコードラボをこれまでに3回開催してきました。Java を使った Web アプリケーションの開発経験はあるけれども、App Engine は初めてという方向けで、毎回、即日定員に達してしまう人気コースです。 このコードラボで利用している教材は、GTUG のメンバーとGoogle のソフトウェアエンジニアたちが共同で作り上げたものです。コース設計からドキュメントの制作、コース参加者のフィードバックを反映するなど、さまざまな面でGTUGメンバーの惜しみない協力をいただきました。 そして、いよいよこのコース教材「Google App Engine Code Lab for Java」を一般に公開することになり、3月11
先日のログ「Google App EngineにDWR2を乗せてみた」で、Google Apps Engine(GAE)にDWR2を乗せて簡単なサンプルを動かしてみた。 GAEに関する記事などを読むと、GAEではファイルIOに制限があるとのこと。「（GAEのプラットフォームを）ファイルシステムと見なして使うことは出来ない」という意味のはずだが（実際に、「JRE クラスのホワイトリスト」を見ると、java.io関連のクラスがたくさん含まれている）、「テキストファイルが全く読み込めない」のでは困る。特に、コンテキストパス配下にテキストを置くことはよくあるので、試しておこうと思う。 以前に「DWR: Javaオブジェクトを画面の要素にマップする」というログで紹介したサンプルが、ちょうどいい実験材料になりそうなので、GAEプロジェクトに移植してみた。このサンプルでは、コンテキストパス配下の以下のよ
本エントリは、エントリ「JJUG CCCいってきました」の一つです。セッションのメモ書きです。もとの発表資料: A-3-1.pdf, A-3-2.pdf スケールするために 無駄な繰り返しを避ける 繰り返されるクエリ結果はmemcacheでキャッシュする(読み込みデータのための) 大きなリザルトセットは避ける メモリ上で大量のデータのソートやフィルタはしない。小さくとって、小さく処理。 チューニングのために知っておく方がいい数字 書き込みはコスト高い。ほんとの最低でも1ms。データ量に応じさらに悪化。 読み込みは速い。25micro second。1秒に4GBのスループット。 EntityとKind 実体は「分散ソートアレイ」と呼ばれるもの。多数のマシン上で実行。 EntityはKeyとvalueをもつ。 valueは、プロパティのキー+バリューをずらりとシリアライズして突っ込んでいるだけ
Google App Engineを使った最初の作品 Tiny Message （http://tinymsg.appspot.com）をリリースしてまだ２０時間経っていないが、設計の過程でいろいろと学べたことがある。 その中でも一番収穫として大きいのは、「Google App Engineを使えば、リニアにスケールするサービスを作ることが可能」だということが実感できたこと。 もちろん、Google App Engine上に作ったからと言ってすべてのアプリがリニアにスケールするわけではなし、どんなアプリでもそう作れるわけではない。Entity Groupの構成を間違えればそこがボトルネックになるし、Queryの二重ループなんかを書いたら、すぐにタイムアウトしてしまう。 リニアなスケーラビリティを持つDatastoreの上で作るとは言え、やはりDatastoreの仕組みをちゃんと理解してデー
カウンタとレコードのシーケンス番号 レコードにシーケンス番号（連番）をつけると、全体の件数を取得できたり、Pagingできたりするので、いろいろと好都合である。Pagingだけであれば、わざわざシーケンス番号を付ける必要はないが、大量のレコードを分割してTaskQueueで並列処理させたい場合には、シーケンス番号で範囲指定を行うとよい。（全体の件数はStatics APIでも取得できる） シーケンス番号を付けるには、カウンタを管理するEntityを用意して、挿入のたびにインクリメントする方法が一般的だと思うが、これだと前記事で述べたように、カウンタのEntityとデータのEntityをEntityGroupとして括ってしまうことが大きなボトルネックとなってしまう。しかし、トランザクションで括らないと挿入に失敗することがあるため歯抜けのシーケンス番号となってしまう。 そこで、カウンタのEnt
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く