基本的には、すべての受信要求に関する粗粒ロックを排除し、スレッド全体で共有される必要のあるそうしたリソースに関する微粒子ロックと置き換えることを 意味する。そこでたとえば、ロギングサブシステム内のデータ構造はスレッドで共有されないように修正されているか、2つのスレッドが互いに干渉しないよう に、またはデータ構造が無効になったり、破損しないように、適切にロックされている。指定されたRailsインスタンスへの単一のデータベース接続の代わ りに、接続のプールがあり、Nデータベースの接続が同時に実行されているM要求によって使用できる。また、接続をコンシュームせずに潜在的に要求を実行す ることができることを意味する。それゆえ、ライブ、アクティブな接続数が、同時処理可能な要求数よりもたいてい少なくなる。コミットやRails Githubリポジトリ(リンク)のコミットメッセージのサンプルを見ると、近ごろスレッドセーフティ関連の作業が実施されていることが分かる。
- 「MemoryStoreは唯一「安全でない」ストアである。デフォルトでスレッドセーフにする」。(リンク)
- 「追加されたconfig.threadsafe!to toggleが同時設置を可能にし、依存ローダーを使用不可に設定する」 - 詳細はコメントを参照のこと(リンク)。
- 「各スレッド用に別々のバッファを保守する」(リンク)。
スレッドセーフティであっても、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