Task Queueのタスクがどのように複数のJVMに負荷分散されるか試したよ #appengine - スティルハウスの書庫の書庫
ご存じのとおり、App EngineのJVM（App Server）はクラスタ化されていて負荷分散される――というのがGoogleの説明です。しかし、WebブラウザからApp Engineに届くHTTPリクエストや、Task Queueのタスクによって呼び出されるHTTPリクエストは、実際にどのような感じで複数のJVMに配られるのでしょうか？ どれくらいの量のリクエストが届いたとき、何台のノードに負荷分散される？ 負荷分散のアルゴリズムは？（単純ラウンドロビン、sticky session/session affinity、負荷状況に応じた転送など） 新しいJVMの追加や、既存のJVMの削除のタイミングは？ これらについてはGoogleから情報が公開されておらず、謎です。そこでApp Engine利用者の皆さんが実際の経験やテストを通じて情報を交換しながら想像たくましくするしかないわけです
Task QueueはMapReduceの夢を見るか - スティルハウスの書庫の書庫
いまコーディング中の案件で、Task Queueにぴったりハマる要件があったので、飛びついてみました。 課題：Datasource上の大量のデータをクライアントにダウンロードしたい。30秒内では終わらないので複数のリクエスト／レスポンスに分割してダウンロードする実装にした。しかしデータ量によっては何10分もかかってしまう。 原因：データ量の多さもあるが、それを取得するためのDatastoreのクエリ、および関連エンティティの取得にもっとも時間がかかっている 書こうとしているソリューション：クエリと関連エンティティ取得をTask Queueのタスクに分割して並列処理（map）し、取得したデータを集約（reduce）してクライアントに渡す …んん、これってMapReduceではないですか。1つのリクエストでは重い処理は、たくさんのタスクに細切れにして、キューにどんどん入れる。App Engin
Task Queue戦記 - スティルハウスの書庫の書庫
とても遅かった以前の実装をTask Queueを使って書き換えることができました。感想をまとめると、 Task Queueはすばらしい。30分かかってた処理が3分で終わるようになった（前の実装がヘボいのではという疑惑はさておき） 処理を複数のタスクに分割して並列処理する（map）は簡単だけど、memcacheを使ってその結果をまとめる（reduce）のは面倒 reduce不要な用途（一括削除とか）や、reduceが簡単な場合（数の集計とか）、あとmemcache使わずにDatastoreに集約する使い方なら、そんなに苦労しないだろう memcacheを介してデータの配布や収集をするとき、とくに収集時の排他を書く必要あり（こういうバグりそうな／バグを再現できなさそうなコードは書きたくない） MemcacheService#incrementを使ってスピンロックを実装した memcacheはい
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
