Railsの総まとめ：Rails 2.2がスレッドセーフ、ETagsがRails Edgeでサポート

作者 Werner Schuster , 翻訳者 編集部 投稿日 2008年9月2日

セクション

デベロップメント,

設計/アーキテクチャ

トピック

Ruby ,

パフォーマンス&スケーラビリティ ,

Ruby on Rails

タグ

Threading ,

Ruby on Rails

近ごろDavid Heinemeier Hansson氏は、長年Railsの問題である、スレッドセーフの欠如をRails 2.2が解決することを述べた(リンク)。Charles Nutter氏は、続けてスレッドセーフなRailsの意味について説明した(リンク)。

基本的には、すべての受信要求に関する粗粒ロックを排除し、スレッド全体で共有される必要のあるそうしたリソースに関する微粒子ロックと置き換えることを 意味する。そこでたとえば、ロギングサブシステム内のデータ構造はスレッドで共有されないように修正されているか、2つのスレッドが互いに干渉しないよう に、またはデータ構造が無効になったり、破損しないように、適切にロックされている。指定されたRailsインスタンスへの単一のデータベース接続の代わ りに、接続のプールがあり、Nデータベースの接続が同時に実行されているM要求によって使用できる。また、接続をコンシュームせずに潜在的に要求を実行す ることができることを意味する。それゆえ、ライブ、アクティブな接続数が、同時処理可能な要求数よりもたいてい少なくなる。

コミットやRails Githubリポジトリ(リンク)のコミットメッセージのサンプルを見ると、近ごろスレッドセーフティ関連の作業が実施されていることが分かる。

• 「MemoryStoreは唯一「安全でない」ストアである。デフォルトでスレッドセーフにする」。(リンク)
• 「追加されたconfig.threadsafe!to toggleが同時設置を可能にし、依存ローダーを使用不可に設定する」 - 詳細はコメントを参照のこと(リンク)。
• 「各スレッド用に別々のバッファを保守する」(リンク)。

Railsにおけるスレッドセーフティの欠如は、Railsアプリケーションに対応するために使用される一連の独立したRuby処理を使用する必要があっ た。言い換えれば、共有しないアプローチを使用することである。一連のテクノロジーやソリューションが問題に対処する目的で開発された。たとえば、 Phusion Passengerは、Copy On Write friendly GCで修正されたRubyバージョンを使用し(参考記事)、Rubyインスタンス全体においてロード済みのコードの共有を可能にする。また、一連の処理の管理を容易に した。一定量のコード共有を可能にした同一のJVMにあるJRubyインスタンスを複数実行することを可能にすることで、JRubyはRailsの複数の インスタンスのコストを下げることを可能にした。

スレッドセーフティであっても、Railsのサイトは拡大縮小するために、複数のRubyインスタンスが必要である。理由の1つは、1.8でのRubyの ユーザスペーススレッドシステムである。単一のブロッキングI/O呼び出しは、インタープリターのすべてのスレッドをブロックする。非ブロッキングI/O は多くのI/Oライブラリで使用される一方で、現在のMysqlアダプタはそれらの1つではない(リンク)(実のところ、インタープリターロックをリリースしていな いCライブラリが原因である)。しかしながら他のDBアダプターは、非ブロッキング要求をサポートしている。たとえば、Postgresqlアダプターな どである。Never_blockはライブラリであり、これらのアダプターの使用を簡単にするが(リンク)、さしあたりRuby 1.9が必要である。

複数のインタープリター間にアプリケーションを散在させることは、またマルチコアシステムの利用を可能にする。しかし純ユーザスペーススレッドは不可である。

Rails Edgeのもう1つの新しい機能は、Simpler Conditional Get Support(リンク)である。

Conditional-getsはHTTPスペックの機能である。GET要求に対する応答が最終要求から変化していないこと、そして安全にブラウザキャッシュからプルできることをブラウザに通知する方法をWebサーバに提供する。

Tim Bray氏はETagsを徹底的に紹介し、解決すべき問題を示している(リンク)。

しかし、単一のタイムスタンプではサーバにとって要求しているコピーをクライアントが必要かどうかを把握するのには、時として情報が不十分である。 ETagsはこの状況のためにある。クライアントがGETを送信するとき、結果と共にHTTPヘッダーを送り返す。 ETag: "1cc044-172-3d9aee80" 引用符の間には、要求されているリソースの現在の状況に対する署名が来る。

原文はこちらです：http://www.infoq.com/news/2008/08/rails-threadsafe-etags-support

• 次へ >