0

I have an application built on top of StreamInsight 1.2 that has several standing queries running some calculations in User Defined Operators. Occasionally one of the calculations will take a relatively long time to complete (a few seconds), and I'm seeing that it blocks the other queries from executing. I'm not very familiar with how StreamInsight works so from this I'm speculating that all queries are run on a single thread. Is there some way to have the queries run in parallel?

Aside from somehow putting the queries on separate threads, are there any other things I could do to prevent one sporadically long running query from blocking other queries?

fred
  • 131
  • 10

2 Answers2

1

Which edition of StreamInsight are you using? Standard Edition runs the scheduler on a single core while Premium uses all available cores. As for the delay, if all of your queries are dependent on the timeline that's hung up - via join, union, etc. - then that's what's causing it to hang up. Events aren't "released" from the long-running UDO to feed the other streams. If this is the case, there isn't anything that you can do unless you can restructure the queries in some way. I'd also start looking into why "occasionally" the UDO will take a few seconds. This leads me to think that there's something amiss with the UDO but then, not knowing the details of what it's doing, I can't say for sure.

DevBiker
  • 451
  • 2
  • 4
  • This might be a dumb question, but I couldn't figure out how to find which edition is installed. The queries are not dependent on the same timeline or the same inputs at all. And it's in the nature of our calculations that it will occasionally take a few seconds. Does StreamInsight provide anything for that kind of use case? – fred Jun 03 '15 at 13:58
  • See http://www.devbiker.net/post/Listing-installed-StreamInsight-instances-e280a6. – DevBiker Jun 04 '15 at 14:56
1

If the calculation will occasionally take a few seconds and that's the nature of it and you are running Standard Edition, the best thing that you can do is to not block the thread while the calculation is taking place. StreamInsight doesn't have anything built-in for this ... it's your responsibility. From StreamInsight's perspective, your UDO is taking some time. It doesn't know why that is. And if the thread is blocked, it can't run anything else until your UDO returns. So I would a) validate that you are running standard edition and then b) if you are, change the UDO so that it's non-blocking/async.

DevBiker
  • 451
  • 2
  • 4
  • Thanks, this is pretty much what I ended up doing so it's good to have external validation. Interestingly, I tried the eval version (which I understand it acts like Premium) and it still only used one scheduler even though there are two cores allocated for this VM. The only difference is that it now uses Scheduler1 instead of Scheduler0 for all the queries. – fred Jun 04 '15 at 18:55
  • You need to be really cautious, however, using async and multiple threads if you are using Premium/Developer ... at high loads, you'll wind up fighting with StreamInsight for thread resources and your overall performance will be *worse* (due to context switching). Question: How many queries do you have running? – DevBiker Jun 05 '15 at 21:38
  • There is only one query in particular that will be offloading work onto a background thread so the performance hit from context switching will be minimal. – fred Jun 05 '15 at 22:34