0

StreamInsight 2.1 を使用していますが、予期しないパフォーマンスの問題が発生しています。

私は、1 秒あたり 5,000 から 10,000 のイベントで入ってくる財務データの入力アダプターを 1 つ持っています。次に、その入力に対して多数のクエリを実行します。各クエリはまったく同じパススルー クエリに接続されるため、まったく同じ入力データを使用するクエリが 1000 あります。

システムがこれを処理できるかどうかをテストするために、イベントをリリースするだけの出力アダプターにイベントをパススルー ( d in fullStream select d から) するだけの 1000 個のクエリを作成しました。

この方法で 1,000 件のクエリを実行すると、システムがストリームについていけなくなります。それはますます後ろに落ちます。これを 100 クエリにトリミングすると、システムは完全に維持されます。

StreamInsight でパフォーマンスの壁にぶつかっただけですか? 私が構築しているタイプのソリューションを処理できませんか? それとも、私はここで何かばかげたことをしていますか....何か助けがあれば、それを速くするために他に何ができるかわからないでしょう。1000 を超えるクエリを実行できるようにする必要があり、これよりもはるかに複雑なクエリを実行する必要があります。

4

3 に答える 3

0

I think you maybe having performance issues because of your current approach.

First off, let's cover the differences between the editions of StreamInsight. Standard edition has only 1 scheduler thread while Premium has one per core. The Evaluation edition is equivalent to Premium.

I think the way to fix this is to reduce the number of queries you have. If you are creating 1000 queries (each with their own instance of an output adapter) I can see where you are going to have issues. On a quad-core machine, you are going to have 4 scheduler threads trying to run 1000 queries.

Are your queries that are arranged "horizontally" doing the same thing? If so, see if you can consolidate them. For instance, if I needed to do a query like the "Price>5 Vol<2k" for 5 different stocks, I would write it in such a way that I can handle all 5 stocks in a standing query that sends all the results to 1 output adapter. If a client is "subscribing" to results from a query, that's something that can/should be handled by your output adapter. You could also turn results on and off for certain stocks by streaming in reference data.

Take a look at the sample below. "sourceStream" is going to be my raw stock data coming from the data source. "referenceStream" is going to be some configuration streamed in from a reference data source (i.e. SQL). The success or failure of the join will throttle the events that get passed on for further processing.

var myPrice5Vol2kSourceStream = from s in sourceStream
join r in referenceStream
on s.StockSymbol equals r.StockSymbol
select s;
于 2012-10-13T06:57:09.433 に答える
0

各クエリには、実行するスレッドが必要です。1000 件のクエリがあります。では、いくつのスレッドが必要ですか? 右。実際、StreamInsight はスレッド プールを使用して、作成されるスレッドの数を制限します。そのため、クエリを実行するスレッドの数は限られています。実際にクエリを実行するよりも、コンテキストの切り替えに多くの時間を費やすことになります。

なぜ1000クエリも必要なのか理解できません。複数のソースから数百のセンサーを取得してまとめて分析するアプリを構築し、1 秒あたり 100,000 件を超えるイベントを取得しました。最後に、問題の原因は StreamInsight 側のパフォーマンスの低下ではなく、アプリの設計の悪さです。

あなたは本当に時間をかけて、これについてどのように行っているかを再考する必要があります. どのようにスライスしても、現在のアプローチでは問題が発生します。そして...これを考慮してください...各入力アダプターは、受信イベントとエンキューイベントをリッスンするために独自のスレッドを作成していますか? ミックスに追加されるスレッドはいくつだと思いますか?

于 2012-10-25T17:58:25.660 に答える