3

Jest クライアントを使用して ElasticSearch をクエリする Java + Spring アプリがあります (文書化が不十分なため、選択が不適切です)。ElasticSearch の応答時間は、150 の同時接続で約 8 ～ 20 ミリ秒ですが、私のアプリは最大 900 ～ 1500 ミリ秒になります。VisualVM をざっと見てみると、プロセッサの使用率が 10% 未満であり、プロファイリングすると、アプリが実行する時間の 98% は次のメソッドを待機していることがわかります。

org.apache.http.pool.PoolEntryFuture.await()

これは Apache HttpCore の一部であり、Jest の依存関係です。Tomcat で実行できるスレッドに関して制限はありません (最大は 200 で、VisualVM によると、実験中のスレッドの最大数は 174 でした)。したがって、空きスレッドを待っていません。

レイテンシーの増加が大きすぎると思います。Jest がすべての要求に対処するのに十分なスレッドを持たない内部スレッドプールを使用していると思われますが、わかりません。

考え？

4

2 に答える 2

4

レイテンシーの増加が大きすぎると思います.Jestがすべてのリクエストに対処するのに十分なスレッドを持たない内部スレッドプールを使用していると思われます...

ClientConfigソースをすばやく調べてみると、Jest クライアント ファクトリにa を挿入できるはずです。

にはClientConfig、内部 Apache http クライアント接続マネージャーに影響を与えると思われる次のセッターがあります。

clientConfig.maxTotalConnection(...);
clientConfig.defaultMaxTotalConnectionPerRoute(...);
clientConfig.maxTotalConnectionPerRoute(...);

それらのいくつかを微調整すると、より多くの接続が得られるでしょうか？JestClientFactoryソースを見て、それが何をしているのかを確認してください。を使用して同じサーバーに多数の接続を行う場合、過去にこれらの値を微調整する必要があったことは間違いありませんHttpClient。

于 2013-10-22T17:02:04.710 に答える