0

私は、Sphinx 2とリアルタイムインデックスをスタンドアロンで、DatamapperとActiveRecordで処理するための一連のgemに取り組んでいます。これを行うために、（明らかに）Sphinxへの接続を開きます。

https://github.com/d11wtq/oedipus

Oedipus.connection("sphinxql.host.tld:9306")

現在、接続の管理については何もしていません... gemのユーザーが接続を確立すると、新しい接続が開かれます。それがそれです。その接続を管理するのはユーザーの責任です。ただし、他のgemはプーリングの概念をもたらしているようであり、シングルスレッド環境では実際には意味がわかりません。

誰かが、なぜプーリングが必要になるのか、私のKISSアプローチの結果はどうなるのか、そしてどのようにプーリングを追加するのかについて教えてくれませんか？プーリングは、スレッドごとに1つの接続が事実上存在するマルチスレッドアプリケーションでのみ本当に意味がありますか、それとも他の有効なユースケースがありますか？マルチスレッドアプリの場合、これはユーザーが想定している宝石よりもうまく管理できるものではないでしょうか。

スレッド化された実装の場合、単純な「無制限の接続」アプローチは次のようになります。

def connection
  Thread.current[:oedipus_connection] ||= connect(args)
end

したがって、スレッドがなくなると、接続もなくなります（リソースが解放されたときにクリーンアップが行われます）。

それは私の頭の中で遊んでいて、組み込みの接続プール/管理がないことが私を悩ませるために戻ってくるのではないかと思っています。

4

1 に答える 1

1

通常、マルチスレッドアプリのみが複数の接続を必要とします。シングルスレッドアプリが複数の接続を利用することは理論的には可能ですが、おそらくその理由はありません。

接続プールの主な利点は、データベース接続を再利用できるように保持し、新しいデータベース接続を設定するオーバーヘッドを最小限に抑えることです。これは、各リクエストが1つまたは少数のデータベースクエリを生成する可能性があるRailsのような一般的な接続ごとのリクエストシナリオで問題になる可能性があります。次に、接続のセットアップが要求時間のかなりの部分になります。

ただし、適切な接続プールシステムを設定するのは少しPITAです。接続のタイムアウトとクリーンアップについて心配する必要があります。例については、 ActiveRecord接続プールコードを確認してください。

適切なインターフェイスを使用してを作成することにより、接続プールについて心配する必要をなくすことができます。それは次のようになります

class MyConnection
    def self.get1(args)
        # establish a connection and return it
    end

    def close
        # close the connection
    end
end

または多分

def use_connection
  connection = nil
  begin
    connection = open_a_connection
    yield connection
  ensure
    connection and connection.close
  end
end

そして、アプリの他の部分に触れることなく、後でインターフェースをより洗練されたものにすることができます。

于 2012-04-29T06:15:20.247 に答える