Google Chrome、マルチプロセスで動作する理由 | エンタープライズ | マイコミジャーナル
Chromium - News and developments from the open source browser project Google ChromeはGoogleからリリースされ、とにかく動作が速いということで注目を集めた。ただし高速なのは興味深いことだが、ほかのブラウザでも積極的に改善が進められているためブラウザ事情に精通したデベロッパはさほど驚かなかっただろう。デベロッパとしてはむしろ、単一のプロセスではなく複数のプロセスを生成して動作するという点に興味を持ったのではないだろうか。Chromeには既存のオープンソースプロジェクトの成果物が活用されているため、実装の新規性よりも組み合わせや改善のうまさが際立つ。新アイディアという点で見ると、Chromeで注目すべきはマルチプロセスアーキテクチャという設計にある。 マルチプロセスアーキテクチャについてはMulti-proc
マルチスレッド・プログラミングの落とし穴、その２
ずいぶん前に、「マルチスレッド・プログラミングの落とし穴、その１（かもしれない）」というエントリーを書いたが、今回はPhotoShareサーバーを運営していて、まさにこのあたりの深い考察が必要になって来たので、良い機会なので続編エントリー。 PhotoShareのバックエンドのようにCRUD（Create/Read/Update/Delete）のAPIをサポートするバックエンドを作る場合、Create/Update/Deleteのリクエストに対してはクライアントからのAPIコール時にすぐに（HTTP Requestに返事をする前に）データベースに変更を加え、Readの際にも（キャッシュを使う・使わないを別にして）データベースの最新の状況を反映するデータを返すように設計するのが普通である。 このアーキテクチャの問題は、ユーザーのアクティビティが増えた時に、データベースやI/Oがボトルネックと
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
