ずいぶん前に、「マルチスレッド・プログラミングの落とし穴、その1(かもしれない)」というエントリーを書いたが、今回はPhotoShareサーバーを運営していて、まさにこのあたりの深い考察が必要になって来たので、良い機会なので続編エントリー。 PhotoShareのバックエンドのようにCRUD(Create/Read/Update/Delete)のAPIをサポートするバックエンドを作る場合、Create/Update/Deleteのリクエストに対してはクライアントからのAPIコール時にすぐに(HTTP Requestに返事をする前に)データベースに変更を加え、Readの際にも(キャッシュを使う・使わないを別にして)データベースの最新の状況を反映するデータを返すように設計するのが普通である。 このアーキテクチャの問題は、ユーザーのアクティビティが増えた時に、データベースやI/Oがボトルネックと
Photo by harry harris いまPhotoShareのサーバの実装を大きく変えようとして悩んでいます。 (参考: Life is beautiful: マルチスレッド・プログラミングの落とし穴、その2) Rails 2.2でThread safeになるとか、NeverBlockで12倍速くなるっていう話もあるんだけど、負荷が上がればレスポンスが悪くなるのは、どうしようもない。マシンを増やせば解決できる部分もあるけど、マシンを増やせばコストは上がる。 Life is beautifulで書かれていますが、確かに全部の処理を同期的に行う必要はないんですよね。 PhotoShareでも、既にいくつかのページは非同期にerbを生成して、それをRailsとerubisで読み込んで実行しています。 しかし、Railsだけではこういった非同期の処理やviewの一部を事前に生成するという処
2008-09-23 23:35追記 そういえばこのエントリはボトルネックがビュー(キャッシュ)の生成で、それが遅いせいでリクエストが詰まってしまう、ということを前提に書いてます。Railsはいまのところシングルスレッドでしか動作しないので、バランサの裏にAPサーバをn本立ててもn本の長寿なリクエストがきた場合、CPUやメモリに余裕があってもブロックされてしまいます。これが問題なのかな、と。 中島さんの方を読むとDBのCRUD(とくにCUD)がボトルネックになってるように見えるのですが、そっちだったらすみません。見当違いです。 追記ここまで。 masuidriveさんのWebでの非同期処理を考えてみるの件で、コメントにしようと思ったんですが、長くなったので自分の日記に。 ちょっと状況がわからないので外しているかもしれませんが(とセルフエクスキューズ)、DBの更新とキャッシュの生成をアトミッ
2008年09月19日04:00 カテゴリNewsiTech これは一本とられた - Dropbox というわけで私も遅まきながら使ってみたけど、これはなるほどだ。 [N] ファイル共有・同期サービス「Dropbox」正式公開! ということで、設定さえしてしまえば後は自分のPCの中にあるフォルダ感覚でファイル共有ができてしまうという「Dropbox」が正式公開なのです。 いやいやちがう。これ、共有(shared)でなくて同期(synched)なところがポイントなのです。 いわゆる共有フォルダーというのは、データはあくまでサーバーにのみ存在し、それにネットワーク経由で各クライアントがアクセスする。だからローカルフォルダーと同様の使い心地を得るには、まずサーバーが生きていなければならないし、回線も速くなければならない。 それに対して、このDropboxにおいては、フォルダーは同期される。ローカ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く