StreamInsight性能问题

Question

我正在使用StreamInsight 2.1，并遇到了意想不到的性能问题。

我有一个金融数据输入适配器，它以每秒5,000到10,000个事件的速度输入。然后，我有大量针对该输入的查询。每个查询连接到完全相同的直通查询，因此我使用完全相同的输入数据有1000个查询。

为了测试系统是否能够处理这个问题，我创建了1000个查询，它们只执行传递(从fullStream选择d中的d)事件到只释放事件的输出适配器。

当我以这种方式运行1,000个查询时，系统无法跟上流。它落得越来越远。如果我将其精简为100个查询，系统就会保持完美。

我是否只是碰到了StreamInsight的性能墙？它不能处理我正在建立的解决方案的类型吗？还是我在这里做了傻事..。任何帮助都是很棒的，不知道还有什么能让它变得更快。我需要它能够执行超过1000个查询，并且我需要运行比这个更复杂的查询。

Answer 1

我认为，由于您目前的方法，您可能会出现性能问题。

首先，让我们讨论一下StreamInsight版本之间的差异。标准版本只有一个调度线程，而高级只有一个内核。评估版相当于高级版。

我认为解决这个问题的方法是减少查询的数量。如果您要创建1000个查询(每个查询都有自己的输出适配器实例)，我可以看到您将遇到哪些问题。在四核计算机上，您将有4个调度程序线程试图运行1000个查询。

您的查询是否“水平”地进行相同的操作？如果是的话，看看你能不能巩固它们。例如，如果我需要为5个不同的股票执行"Price>5 Vol<2k“这样的查询，我将以这样的方式编写它，以便能够在一个将所有结果发送到一个输出适配器的常设查询中处理所有5个股票。如果客户端正在“订阅”来自查询的结果，则可以/应该由输出适配器来处理。您还可以通过在引用数据中流动来打开和关闭某些股票的结果。

看看下面的样本。"sourceStream“将是我从数据源获得的原始股票数据。"referenceStream“将是从引用数据源(即SQL)中流进来的一些配置。连接的成功或失败将扼杀传递给进一步处理的事件。

var myPrice5Vol2kSourceStream = from s in sourceStream
join r in referenceStream
on s.StockSymbol equals r.StockSymbol
select s;

Answer 2

每个查询都需要一个线程来执行。您有1000个查询。所以你需要多少线索？正确的。实际上，StreamInsight将使用线程池来限制创建的线程数量。所以..。执行查询的线程数量有限。最后，您将花费更多的时间进行上下文切换，而不是实际执行查询。

我不明白你为什么需要1000个查询。我们已经建立了应用程序，从多个来源接收100多个传感器，并一起分析它们.每秒钟超过100000个事件。最后，导致问题的是你的应用程序设计不佳，而不是StreamInsight的性能不佳。

你真的需要花点时间重新考虑一下你是怎么做的。无论您如何分割它，您当前的方法都会引起您的问题。还有..。想想这个..。每个输入适配器是否创建自己的线程来侦听入站和队列事件？你认为这会增加多少线程？

Answer 3

这听起来确实是个大问题。您已经确定您可以在服务器上运行100个查询，而不存在任何问题。然后，在您对其他答案的评论中，您讨论的是成千上万的客户添加了数千个查询。有了这么多客户，我怀疑您将能够负担得起添加新服务器来满足这些大量客户的需求。

所以通过分散负载来增加吞吐量，也许是通过某种形式的分布式计算--我不知道？