約半月で 4,000,000PV を華麗にさばく Google App Engine
「なんでも判定ツクール」へ多数のアクセスありがとうございますm(_ _)m 1月末にリリースした当初は僅かのアクセスだったのですが、Twitterで火が付いてからは一気にアクセスが集まり、気が付けば2月1日〜2月16日で4,000,000PVを超えました。 自分では絶対に考えつかないであろうユニークな判定がたくさんできて、私自身もとても楽しんでいます:-D（面白い発想をする人は世の中にたくさんいるものです） このサイトはGoogle App Engine(GAE）＋Pythonで構築しているのですが、このアクセス数ならではのGAE上で体験できたことをざざっと書いていきます。 無料？課金？ まずはじめに大事なこと。 「なんでも判定ツクール」ではGAEを課金状態にしています。無料のQuotaではとてもではないですが、このアクセスは捌けません:D GAE公式サイトには 月間約 500 万ページ
Song of Cloud: 送金のトランザクション処理パターン
App Engineで現実的な送金処理について考え中です。 ドラフト版なので、怪しい点があればご指摘いただければ幸いです。 コメントで情報いただきました。 Distributed Transactions on App Engineで紹介されてる方法と基本的に同じなので、おそらく問題なく動きそうです。ありがとうございました。 今回はこんな図を使います。 この図の読み方は、矢印の方向にユースケースの一連の処理(またはリクエストの処理)が流れていて、右に行くほど時間が経過しています。そして、矢印がくし刺しにしている四角形は、そのユースケース中で操作するエンティティを表しています。 また、左右の位置が同じ矢印は、基本的には同じ時刻に発生したイベントを表しています。上記の図では、A, B, Cがそれぞれの口座エンティティを同時に操作している感じです。 並行性制御(おさらい) 最初の図のように、それ
エンティティを２つに分けます - How BuddyPoke Scales on Facebook Using Google App Engine - urekatのスカンク日記３
http://highscalability.com/blog/2010/1/22/how-buddypoke-scales-on-facebook-using-google-app-engine.html エンティティを２つに分けます：メインモデルとサブモデル。 Datastoreのputはもっとも大きなコスト要因なので削減するためにできることはなんでもやりましょう。 メインモデルにはkeyだけでアクセスします。 インデックスは一切作らないし、余計なフィールドも一切保存しないようにします。 getのスピードは速くなり、putにかかる料金は安くなります。 余計なフィールドは時間もお金も無駄にすることになります。 だからUserモデルの「入会日時」フィールドはメインモデルには含めません。 このような頻繁に使わないフィールドはサブモデルに入れておきます。 サブモデルに対してインデックスを作り、
Google App Engine上のベスト・プラクティス、その１: Datastore
Google App Engine上でアプリを作りはじめて約二ヶ月。いろいろと分かって来たこともあるので、自分へのメモも含めてまとめてみる。まずは、Datastoreの話から。 なによりも大切なのはデータベースの設計 あたりまえと言えばあたりまえの話だが、App Engine上でアプリを作る上でもっとも大切なこと（＝頭を使うべきところ）は、データベースの設計である。特にリレーショナル・データベース（RDB）上でのアプリ作りに慣れた人には、大きな「発想の転換」が必要なので、ここは注意が必要。 特に絶対にやっては行けないのは、 将来RDB上へ移行できるようにレイヤーを作って、その上にアプリを作る RDB上に作ったアプリをデータモデルを大幅に変更せずにApp Engine上に移植する RDBを前提に設計されたフレームワークをApp Engine上に載せて、その上にアプリを作る など。App En
Google App Engineのプロパティ名は可能な限り短いほうがいいかもしれない - 2010-02-05 - きしだのはてな
他の話を期待してる人も多いと思うのだけど、まとめるのに時間がかかりそうなので小ネタを。 まず、このエンティティ使用状況をみてください。 これ、http://kistools.appspot.com/rateで格納されているエンティティのひとつなんですけど、Metadataが85%になってます。 内訳はこんな感じで、Integerのプロパティが２つあって、あとはMetadataです。 同じIntegerでも利用率が違うというのも面白いところですが、確かに上のプロパティのほうが桁数が大きいデータが入ってるとはいえ、これは誤差かも。 ところで、Metadata。 Google App Engineのデータストアは、それぞれのエンティティにプロパティ名まで格納しているはずです。 ということは、長いプロパティ名を使うとそれだけMetadata容量が増えてしまう。特にログのように量の増えがちなデータに
Song of Cloud: グローバルトランザクション処理のパターン
送金のトランザクション処理パターンでは、Google App Engine (GAE)のEntity Groupにまたがるトランザクション処理を行う方法について紹介しました。また、それに少しだけ最適化を施した結果、下図のような処理になりました。 しかし、このトランザクション処理はいくつかの制約があります。 (a) 送金中に合計金額がずれる (b) 送金先の口座に制約をかけられない このトランザクションはEventual Consistency (結果整合性)というレベルの整合性保証しかしないため、2つのEntity Groupの値にずれが発生する場合があります(a)。たとえば、口座(A)から口座(B)に1000円だけ送金する場合、(1)と(2)の間は「口座(A)から出金したが、口座(B)に入金されていない」という状態になります。 また、送金元の口座に制約はかけられますが、送金先の口座に制約
Google App Engine入門：実行効率を犠牲にせずに開発効率だけを上げるテクニック
一つ前の富豪プログラミングのエントリーともつながる話だが、Google App Engineは「ちゃんとスケーラビリティを考慮してアプリケーションを作るには何に気をつけなければならないか」を勉強するには絶好の環境だ。そこで今回は、その「ケチな大富豪的なプログラミング」の実践編。 Google App Engine上のアプリをいくつか書いているうちに、必要に迫られて自然発生的にできてきたのが、gdispatchという数十行のコードからなる小さなモジュール（ソースコードはgithubに置いてある）。これをGoogle App Engineに標準で付いて来るwebappと組み合わせてフレームワークとして使っている。 gdispatchを設計する上で重視したのは、 （１）Google App Engine上でのアプリの開発を効率化する上で「明らかにこれがあると開発効率が格段に向上する」というもの以
App Engineのユニーク制限を正しく理解しよう - ひがやすを技術ブログ
Google App EngineではRDBMSのようなUnique Indexをサポートしていません。ユニーク制限を実現する場合は、トランザクション中でKeyを使ったgetとputを組み合わせる必要があります。 ここでは、email addressがユニークだったらそれを確定してtrueを返し、そうでない場合にはfalseを返すコードを考えます。 最初にトランザクションを使わないコードを見てみましょう。KeyFactory.createKeyの最初に引数は、kindといってテーブル名みたいなものです。 public boolean putUniqueEmailAddress(String value) { DatastoreService ds = DatastoreServiceFactory.getDatastoreService(); Key key = KeyFactory.cr
Google App Engine入門：Datastore上で「ユニーク制限」を実現する方法
Google App Engine のDatastoreには、通常のリレーショナルデータベースと比べた時にいくつかの制限があるが、その一つが「このプロパティの値は常にユニークでなければならない」という指定（ユニーク制限）ができないことである。 Invoice IDのように自動生成するものであれば、アプリケーション側でなんとかすることも簡単だが、メールアドレスやハンドル名など、ユーザーが入力するものになると、ユニークであることをきちんと判定した上でEntityを作ることが必要になる。 もちろん、単純に「有無をチェックして、なければ作る」というプログラムではスレッド間の競合に対応できないので、そこはトランザクションを使ってアトミックに処理をする必要がある。 App Engine上でトランザクションを実現するには、エンティティグループという仕組みを使って行うが、気をつけなければいけないのは、エン
Slim3 for GAE/J ひがさん - uehaj's blog
本エントリは、エントリ「JJUG CCCいってきました」の一つです。 （補足）のところが主に自分で考えたところ。でも他にも暗に補完してると思うのでそこんとこよろしくお願いいたします。 はじめに Amazon EC2は仮想化サービスであり既存技術と連続 Google AppEngineは既存技術に対する制約が大きく連続性がない 制約とは Threadが使えない ContextClassLoaderが使えない セキュリティが厳しい。seculity.policyの設定が厳しい。 → Spring 2.5からコンポーネントスキャンというのをやってアノテーションを読み取るのだがそれは動かない。 Struts2の式言語はOGNLを使うがセキュリティマネージャを設定していると駄目 → nullにすれば良い ファイルに書き込みできない Apache Commonsのファイルアップロードはテンポラリファイ
GAE/JでJavassist - たぷつきません
使える機能をうまく選択することで制限付きながらGAE/JでJavassistが扱えます。 GAEではクラスパスが無いのでルックアップがうまくいきません。サーブレットやフィルタのinit()で以下のようにクラスパスを登録しておきます。 ClassPool pool = ClassPool.getDefault(); pool.appendClassPath(getServletContext().getRealPath("WEB-INF/classes")); for (File file: (new File(getServletContext().getRealPath("WEB-INF/lib")).listFiles())) { String jarPath = file.getAbsolutePath(); if (jarPath.toLowerCase().endsWith(".
Google Sites: Sign-in
Not your computer? Use a private browsing window to sign in. Learn more about using Guest mode
2009-06-06 - おおたに6号機blog - Google Sitebricks
JavaOneでGoogleの新しいWebフレームワークが発表されたみたいですね。 その名もSitebricks。GWTベースのようです。 まずは見てみてください。JavaOne資料から抜粋。 POJOコード。 class MyPage { @Property String meaning = “17”; } テンプレートはこちら。 <body> The meaning of life is: ${meaning} </body> PageとURLをマッピングして、そのプロパティがJSPのELでマッピングといったところ。 とまあここまではまあ普通。 ところが、例えば以下のようなtypoをすると、コンパイルエラーになります。 どうやらコンパイル時にチェックするみたいですね。 型の不一致とかもチェックするみたい。 class MyPage { //typoしてるよ！ @Property Str
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Index of /gaejtools-wicket-util/src/main/java/appengine/wicket - Tools for Google App Engine/Java - OSDN
