問題タブ [pooling]

私は「オブジェクトプール」を開発しましたが、「悪い習慣」であるThread.Sleep（）を使用せずにそれを行うことはできないようです。

これは、私の他の質問「.netに独自の接続プールを実装する標準的な方法はありますか？」に関連しています。オブジェクトプールの背後にある考え方は、データベース接続に使用される接続プールの背後にある考え方と似ています。ただし、私の場合は、標準のASP.NET Webサービス（IIS6で実行）で限られたリソースを共有するために使用しています。これは、多くのスレッドがこの限られたリソースへのアクセスを要求することを意味します。プールはこれらのオブジェクトをディッシュし（「Get」）、使用可能なすべてのプールオブジェクトが使用されると、次のスレッドは、これらのオブジェクトの1つが再び使用可能になるまで、設定された時間だけ待機します（スレッドはオブジェクトで一度実行された「プット」）。この設定時間内にオブジェクトが使用可能にならない場合、タイムアウトエラーが発生します。

コードは次のとおりです。

それを使用するには、次のようにします。

今私が持っている質問は次のとおりです：Thread.Sleep（）を取り除くためにこれをどのように書くのですか？

（これを実行したいのは、テストで取得している「false」タイムアウトの原因であると思われるためです。テストアプリケーションには、3つのオブジェクトを含むオブジェクトプールがあります。12スレッドをスピンアップし、各スレッドが取得します。プールからオブジェクトを100回取得します。スレッドがプールからオブジェクトを取得した場合、2,000ミリ秒の間保持し、取得しなかった場合は次の反復に進みます。ロジックは、9つのスレッドが待機することを指示します。 9 x 2,000msは18,000msで、これはスレッドがオブジェクトを待機する必要がある最大時間です。gettimeoutは60,000 msに設定されているため、スレッドはタイムアウトしません。間違っていて、そのThread.Sleepが疑われます）

Hibernate 3 を使用していますが、接続が閉じられていることに関連する問題に直面しています。

c3p0-0.9.1.2.jar を使用しており、Hibernate によって開かれたデータベース サーバーへの接続を確認したところ、5 つの接続が確立されていることがわかりました。サーバーの一部の TCP ポートで (以下のログを参照)。

ただし、これらの確立された接続は、確立された TCP ポートを変更し続けるため、それらが使用していた以前のポートを解放し、これらのポートを (閉じるのではなく) TIME_WAIT 状態にします。

これは継続し、数百の数を数えます。TIME_WAIT 状態の接続の場合。

何が起こっているのか、ポートが確立された状態から TIME_WAIT に切り替わっていて、以前のポートが閉じていない理由がわかりません。

以下は、NETSTAT -ano|find "x.9" を実行して取得したサンプルです。x.9 はデータベース サーバーの IP です。

私が使用する Hibernate.properties ファイル。

手伝ってくれてありがとう。

Tomcat 6 の下のサーブレット 101:

誰かが親切に、例えばの最善の方法の良い説明を教えてくれませんか。サーブレットの起動時に高価な Foo オブジェクトの Collection を作成し、各リクエストの処理中にアクセスできる場所にそれらを隠しますか?

私が知る限り、これを行うには少なくとも 3 つの方法があり、その違いについては少し曖昧です。古いエントリを削除するためのクラスタリングやアルゴリズムなどには関心がありません。基本的なことだけです。

乾杯と感謝。

アプリケーションの一部にプーリングを実装しようとしています。close()Commons Pool ライブラリを使用したいのですが、動作が少し気になります。close()javadoc とソース コードを見ると、メソッドが呼び出されたときにプールで作成されたオブジェクトが破棄されるかどうかは明確ではないようです。私が見る限り、プールでアイドル状態のオブジェクトのみが破棄されます。使用されていて、まだ返されていないオブジェクトには触れられません。

ここで何かを見逃しましたか？プールが閉じられたときに、すべてのオブジェクトが正しく破棄されるようにしたいと考えています。

誰もこれを以前に使用していて、それがどのように機能するかについて考えを持っていますか?

EJB を使用したインスタンス プーリングはどのようにパフォーマンスを向上させることができるのでしょうか? Java サーブレットのようなスレッドだけで同じパフォーマンスを達成できないでしょうか?

それとも、別の理由で EJB を使用したインスタンス プールが発生するのでしょうか?

IBMWebsphereMQを介して通信するカスタムWCFチャネルを開発しました。

チャネルファクトリを作成しました。

これは、チャネルのインスタンスを返します。

IBM MQキュー・マネージャーへの接続は、コストのかかる操作です。現在、これはChannel.OnOpen（）で行います。

チャネルを正しく使用するためのガイドラインに従って、チャネルが必要になるたびにChannelFactory.CreateChannel（）を呼び出し、メッセージを送信してからChannel.Close（）を呼び出します。

ChannelFactoryがチャネルのプーリングを実行したため、Channel.Close（）が呼び出されたときに、チャネルは実際には閉じられず、プールに戻されたと想定しました。ただし、ChannelFactory.CreateChannelを呼び出すたびに、新しいチャネルがインスタンス化され、要求が送信されると、高価なチャネルのオープンが実行されます。

それで、質問：すべての要求でチャネルが開かれるのを防ぐための最良のアプローチは何ですか？

私たちが調査しているオプションのいくつか：

• とにかく、チャネルプーリングを実行するように指定する構成はありますか？ChannelFactoryに独自のチャネルプーリングを実装する必要がありますか？

• アプリケーションの存続期間中、チャネルを開いたままにして、すべてのリクエストをアプリケーション経由で送信する必要がありますか？

• アプリケーションの存続期間中キャッシュするチャネルファクトリで、コストのかかる操作（キューマネージャへの接続）を実行する必要がありますか？

外部システムから返されるセッションのプールを実装する必要があるため、必要になったらすぐに再利用できます (セッションの作成には時間がかかります)。私はデータソースを使用してデータベース接続のプール (Apache からの DBCP) を作成しましたが、これは実装されたソリューションでした。

一般的なケースでは、任意のオブジェクトをプールするために何を使用しますか? また、そのタスクを苦労して処理するために実装されたソリューション、つまりインターフェイスではなくオブジェクトはありますか?

2 番目の質問は、セッションが生きているかどうかをどのようにテストするかということです。セッションの独自のメソッドを照会する、オブジェクト プールでオーバーライドする特定のメソッドはありますか?

3 番目の非常に重要な質問は、オブジェクト プーリング オブジェクトを staticにする必要があるかどうかです。システムから抽出したオブジェクトのバンドルは、異なる Web アプリケーション間で共有する必要があります。たとえば、5 つのセッションを抽出します。アプリ A は POOL にクエリを実行し、最初に利用可能なセッションを取得します。これで、残り 4 つのセッションがあります。別のアプリ B が起動し、THE SAME POOL を照会します。etc プールは共有です。同じマシン上で実行されている、同じ Web アプリの異なるインスタンス間。

SendAsyncsのBeginAsyncメソッドの図を読んで、各呼び出しでインスタンスが作成されるため、BeginXX、EndXX非同期アプローチよりも優れていると言ってインスタンスSocketをプールすることが提案されていることに気付きました。SocketAsyncEventArgsIAsyncResult

簡単にインスタンス化できるオブジェクト（などSocketAsyncEventArgs）をプールするのは、それほど良い習慣ではないと思いました。オブジェクトの割り当ては非常に高速で、GCは短命のオブジェクトを効率的に処理するように最適化されています。プーリングメカニズムを実装して、そのパフォーマンスを確認してみました。実際には、一部のデータをctorにカプセル化するだけの単純なオブジェクトでは、割り当てが高速です。（まあ、それは何十億ものステートメントを送信することによってDBMSをプロファイリングするようなものでした。それがSELECT 1私がここにいる理由です。）

どちらが優れているかは問いません。実際のアプリケーションをプロファイリングすることで答えが得られると思いますが、単純な短い生物をプールすることの利点について知りたいだけです。より良いGCパフォーマンス？低メモリの断片化？設計時に検討する価値はありますか？

MSDNから

これらの拡張機能の主な機能は、大量の非同期ソケットI/O中にオブジェクトの割り当てと同期が繰り返されないようにすることです。System.Net.Sockets.Socketクラスによって現在実装されているBegin/Endデザインパターンでは、非同期ソケット操作ごとにSystem.IAsyncResultオブジェクトを割り当てる必要があります。

新しいSystem.Net.Sockets.Socketクラスの機能拡張では、非同期ソケット操作は、アプリケーションによって割り当てられ、維持される再利用可能なSocketAsyncEventArgsオブジェクトによって記述されます。高性能ソケットアプリケーションは、維持する必要のあるオーバーラップしたソケット操作の量を最もよく知っています。アプリケーションは、必要な数のSocketAsyncEventArgsオブジェクトを作成できます。たとえば、サーバーアプリケーションは、着信クライアント接続レートをサポートするために常に15個のソケット受け入れ操作を実行する必要がある場合、その目的のために15個の再利用可能なSocketAsyncEventArgsオブジェクトを割り当てることができます。

ありがとう。

Sql接続プーリングの静脈で限られたリソースのための共有オブジェクトプール戦略を実装するための良いリソースを持っている人はいますか? (つまり、スレッドセーフであることを完全に実装します)。

明確化のための@Aaronaughtリクエストに関してフォローアップするには、プールの使用は、外部サービスへのリクエストを負荷分散するためのものです。私の直接の状況とは対照的に、おそらくすぐに理解しやすいシナリオに入れる. ISessionNHibernateのオブジェクトと同様に機能するセッション オブジェクトがあります。各一意のセッションがデータベースへの接続を管理すること。現在、実行時間の長いセッション オブジェクトが 1 つあり、サービス プロバイダーがこの個々のセッションの使用率を制限しているという問題が発生しています。

単一のセッションが長時間実行されるサービス アカウントとして扱われることを期待していないため、明らかに、サービスを攻撃しているクライアントとして扱っています。ここでの質問は、1 つの個別のセッションを作成する代わりに、異なるセッションのプールを作成し、以前のように単一のフォーカル ポイントを作成するのではなく、それらの複数のセッションにわたってサービスへのリクエストを分割することです。

背景が何らかの価値を提供することを願っていますが、いくつかの質問に直接答えるために:

Q:オブジェクトの作成には費用がかかりますか?
A:オブジェクトは限られたリソースのプールではありません

Q:それらは非常に頻繁に取得/リリースされますか?
A:はい、繰り返しになりますが、これらは NHibernate ISessions と考えることができます。通常、1 ページ要求ごとに 1 が取得され、解放されます。

Q:シンプルな先着順で十分でしょうか、それとも飢餓を防ぐなど、よりインテリジェントな方法が必要ですか?
A:単純なラウンド ロビン型の配布で十分です。スターベーションとは、使用可能なセッションがない場合、発信者がリリースを待ってブロックされることを意味していると思います。セッションは異なる呼び出し元によって共有される可能性があるため、これは実際には当てはまりません。私の目標は、1 つのセッションではなく、複数のセッションに使用を分散することです。

これはおそらくオブジェクト プールの通常の使用法からの逸脱であると考えているため、最初はこの部分を省略し、飢餓状態が発生するのではなく、オブジェクトを共有できるようにパターンを適応させることだけを計画しました。

Q:優先度、レイジー ローディングとイーガー ローディングなどについてはどうですか?
A:優先順位付けはありません。簡単にするために、プール自体の作成時に使用可能なオブジェクトのプールを作成すると仮定します。

C# を使用したオブジェクト プーリングはいつ行うべきか? どんな良い元...

頻繁に使用されるオブジェクトのプールを維持し、新しいオブジェクトを作成する代わりにプールから 1 つを取得することの長所と短所は何ですか?