AppEngine/Jのspin-upを劇的に改善する方法 - ひがやすを技術ブログ
AppEngineは、アクセスがあったときにアプリケーションを起動し、しばらくアクセスが無ければアプリケーションを終了させ、また次のリクエストで再起動するという仕組みを導入しています。 そのため、アプリケーションを起動(spin-up)する時間がとても重要になってきます。このspin-upの時間はpython(webapp)で60cpu_ms以下。(cpu_msはcpuが使う仮想的な時間ですがmsと同じ感じで捉えてもらってもとりあえずは大丈夫です)JavaのServletだと600cpu_msくらいです。PythonでもDjangoような大きなフレームワークだと1000cpu_msくらい(アプリによる)かかりますが、許容範囲内。JavaだとSlim3で1300cpu_ms、Springだと早くて7000cpu_msという感じで、Slim3がギリギリ許容範囲内でしょうか。ほんとうは、1000
App EngineのEntityGroupを理解しよう - ひがやすを技術ブログ
App EngineのEntitiGroupは、Keyの親子関係を利用して組み立てられたEntityの集まりです。 Entityとは、Bigtable上の1つの行で、ユニークに識別するためのKeyを持っています。 Keyは、種類をあらわすkindとAppEngineから自動的に採番されるidもしくはアプリケーション側で自由に決めることのできるnameで構成されます。 通常は、AppEngineの自動採番に任せますが、Emailのアドレスをキーに使いたい場合などは、nameを使います。kindはテーブル名のようなものだと思ってください。 Keyの親子関係は次のようにして作ります。 Key grandparentKey = KeyFactory.createKey("Grandparent", "しげお"); Key parentKey = KeyFactory.createKey(grand
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
App Engineでバージョンによる楽観的排他制御 - ひがやすを技術ブログ
Song of Cloudで送金のトランザクション処理パターンが紹介されていました。 http://songofcloud.gluegent.com/2009/11/blog-post_18.html 同様のpython版がこちら Distributed Transactions on App Engine - Nick's Blog 上記のやり方で基本的には問題はないのですが、バージョン管理による楽観的排他制御を行っていないので、送金だけを考えるなら、残高を差分で更新しているので大丈夫ですが、これを一般的なパターンに拡張しようとすると、楽観的排他制御は必要になります。 楽観的排他制御とは、エンティティにバージョン番号を持たせておいて、メモリ読み込んだときのバージョン番号と書き込むときのバージョン番号が等しいことを確認する方法で、RDBMSの場合は、次のようなSQLを実行することで実現しま
AppEngineのDatastoreの学び方 - ひがやすを技術ブログ
Google AppEngineではBigtableの上にDatastore Serviceが構築されていて、開発者は、このDatastore Serviceを利用してBigtableにアクセスすることになります。このDatastore ServiceはPython版もJava版も機能はほとんど同じです。もしかすると、全く同じものかもしれません。 GAE/Jの場合、JDOを通じて、Datastore Serviceを利用するのが推奨されていますが、実はこれが嵌りポイント。 JDOは汎用的なインターフェースなので、Datastore Serviceを理解するのには向いていません。Datastore ServiceがRDBMSのような高機能なら、JDOを通じて抽象化し、Datastore Serviceのことは知らなくても済すのもぜんぜんありなのですが、残念ながら、そうなってはいません。 Da
Slim3 Preview release - ひがやすを技術ブログ
Slim3の正式リリースは、来年の一月くらいになりそうですが、ドキュメントも最低限のものはそろったので、今の段階のものをPreview版として紹介しておきます。 サイトへは、http://slim3.org でアクセスしてください。 Getting Startedをやり、Slim3 Datastoreのドキュメントを読み、Online demoをみれば、Slim3のことは把握できるようになっています。 Oneline demoからソースも見れるようになっているので、動かしながらソースを確認することができます。Online demoは、IE6で見るとレイアウトが崩れていますが、これはIE6を使うなというメッセージということで。(IE7,8では未確認) Slim3は、Google App Engineに対して最適化されています。 例えば、最近、App Engineで問題になっているのは、spi
TaskQueueをローカルでデバッグする方法 - ひがやすを技術ブログ
SDK 1.2.5からGoogle App EngineにTaskQueueが導入されましたが、ローカル(development server)でデバッグはできないと思っている人が結構いるようなので、やり方を書いておきます。 ローカルの環境では、Queueにaddしたタスクは、自動的には実行されず、Queueにたまっています。たまっているタスクを実行するには、http://localhost:8080/_ah/adminにアクセスし、左側のTask Queuesのリンクをクリックします。 すると、Queueの一覧が表示されるので、そこでQueueのリンクをクリックすると、タスクを実行する画面に遷移します。そこで、runのボタンを押すと、ローカルでQueueのタスクを実行できます。 Web ApplicationをDebug Asで起動しておけば、EclipseからDebugすることもできま
GAEでunownedな関連を定義する方法 - ひがやすを技術ブログ
Google App Engineでは、関連の実装として、キーの親子関係で実現するownedな関連と、キーの親子関係ではなく、単に相手のキーを持つだけのunownedな関連があります。 unownedな関連は、RDBMSにおけるFKを持っているようなものだと思うとイメージしやすいと思います。 例えば、次の例では、FooがBarをunownedな関連先として定義しています。 @PersistenceCapable(identityType = IdentityType.APPLICATION, detachable = "true") public class Foo { @PrimaryKey @Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY) @Extension(vendorName = "datanucleus", ke
HOT reloadingとClassLoaderを理解しよう - ひがやすを技術ブログ
JavaではClassはClassLoaderに読み込まれます。これはほとんどの人が知っていると思います。AOPを使うときのエンハンスされたクラスも同様にClassLoaderに読み込まれます。 これらの情報は、パーマネント領域に格納されますが、ClassLoaderがGCされると解放されます。 Seasar2のHOT reloadingでは、リクエストの度にClassLoaderを作って、そこにClassをロードし、そのClassLoaderは、リクエストが終わったら破棄しているので、Classの情報は、リクエストごとに破棄されています。 HOT relodingによって、パーマネント領域が使いつくされることはありません。 さらっと書きましたが、きちんとClassLoaderを破棄するのは、かなり大変です。リフレクションの情報がキャッシュされているとそれだけで破棄されなくなってしまうから
GAE/Jで開発サーバのときだけ振る舞いを変えたい - ひがやすを技術ブログ
GAE/Jで開発サーバのときだけ振る舞いを変えたいことがありますよね。例えば、Slim3のHOT reloadingオプションを開発のときはtrueで、本番サーバのときはfalseにするときなど。 開発用のサーバかどうかは、ServletContext.getServerInfo()が返す値にDevelopmentが含まれているかどうかで知ることができます。 これを利用して、最新のSlim3では、開発用と本番(Cloud)用で自動的にHOT reloadingのオプションが切り替わるようになりました。うっかり本番用のサーバにHOT reloading:trueでデプロイしてしまうこともなくなります。
半年間Slim3の開発に集中する - ひがやすを技術ブログ
Slim3は、この半年間、ずっと構想を練ってきたわけですが、10月からいよいよ本開発に入ります。なぜ、半年間も構想を練っていたかというと、SAStrutsとS2JDBCの開発が続いていたからというのが主な原因です。 なぜなら、Slim3は、SAStrutsとS2JDBCをポーティングしようとしているので、ポーティング元が安定してないと、二重にメンテナンスをしなければいけなく、負担が大きくなってしまうためです。 半年間待っている間に、状況も大きく変わってきました。一番大きいのは、Springのメンテナンスポリシーの変更ですね。 Springの新しいメンテナンスポリシーでJava界の勢力図が変わる もともと、Slim3は、Springコミュニティに対して、Seasar2で人気のあるHOT deployの機能とSAStrutsを提供しようというつもりで企画しました。 しかし、Springの新しい
IT業界の重鎮に期待せず、アルファギークと学生の討論会はいかが - ひがやすを技術ブログ
@IT:「10年は泥のように働け」「無理です」――今年も学生と経営者が討論 ITpro「IT技術者はやりがいがある仕事か」---学生とIT産業のトップが公開対談 みんな@ITに釣られすぎ。重鎮たちの意見は、古いなぁとは思うけど、そんなにおかしいことは言ってない。ITproとあわせて読めば、@ITが意図的に煽っているのがわかると思う。 なんか@ITの記事が最初見たときと違っている気がするけど気のせいかなぁ。 とはいえ、重鎮たちと学生を討論させても、学生がIT(SI)業界に夢を持ってくれるとは思えないので、ここで1つ提案をしたい。 小飼弾のアルファギークに逢ってきたのメンバーと学生会の討論会を開くのだ。 もちろん、司会は、ダンコーガイ。いいよね、弾さん。 ゼッタイに面白いと思うし、学生のイメージアップ間違いなし。重鎮たちに文句を言うだけよりも、自ら動いたほうがゼッタイ良い。 技術評論社さん、ぜ
S2JDBC & Hibernateベンチマーク その2 - ひがやすを技術ブログ
今度は、Addressを10000件取得してみます。Addressは、EmployeeとOneToOneの関連があり、外部キーを持たない非所有者側のエンティティです。 S2JDBC(0.453489233) 0.454608859 0.451351731 0.454507110 Hibernate(26.278606800) 26.353926022 26.258951969 26.222942410 Hibernateは、S2JDBCより約58倍時間がかかっています。HibernateはOneToOneの非所有者側のエンティティを取得するのは苦手です。10001回のSQLを発行してしまうのです。 下記のSQLは最初に1回発行されます。 select address0_.ADDRESS_ID as ADDRESS1_1_, address0_.STREET as STREET1_, add
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
