1

我正在从一台机器测试 Azure 事件中心。

我有一个具有最大允许分区 (32) 的事件中心。

我发现写入集线器的速度非常快——基本上是 1000 条消息/秒。但是，当我尝试提取数据时，我并没有获得几乎相同的吞吐量。提取 1000 条消息大约需要一分钟。

我已经尝试过使用 32 个并行接收器的 Direct 方法和 EventHost 方法。两者在速度方面大致相同。

我已将所有设置保留为默认设置。

是因为我使用单台机器来提取数据吗？请注意，从同一台机器写入不是问题。

更新：这是我用于从事件中心提取数据的代码（直接版本）：

let startDirectPump
    stream
    eventHubConnectionString
    storageConnectionString
    fPost =
    let tag = "startEventHubPump"
    let client = EventHubClient.CreateFromConnectionString(eventHubConnectionString,stream)
    let cg = client.GetDefaultConsumerGroup()
    let runtimeInfo = client.GetRuntimeInformation()
    let pCount = runtimeInfo.PartitionCount
    let receivers =
        [for p in 0..pCount - 1 ->
            cg.CreateReceiver(runtimeInfo.PartitionIds.[p],System.DateTime.UtcNow)
            ]
    let tasks =
        receivers
        |> List.map (fun r ->
            async {
                try 
                    while not r.IsClosed do
                        let! e = r.ReceiveAsync() |> Async.AwaitTask
                        if e <> null then
                            fPost e
                with ex ->
                    do! Async.Sleep 5000
                    Logging.logex "eh receive" ex
            })
    tasks |> Async.Parallel |> Async.Ignore |> Async.Start
    client
4

4 回答 4

3

如果您的目标是将数据泵入 Storm，实际上正在进行集成以提供将 EventHub 数据导入 Storm 的适配器。请看代码@https ://github.com/hdinsight/hdinsight-storm-examples/tree/master/lib

至于找出延迟问题，您可能想尝试许多事情：

  • 启用 ServiceBus 性能计数器以查看接收延迟。您可以按照示例@ https://code.msdn.microsoft.com/windowsazure/Service-Bus-Messaging-7a0a0761
  • 您的代码使用 DateTimeUtc 作为检查点标记。我想知道您是否可以尝试使用偏移量作为标记来查看是否有性能改进（使用日期时间作为标记将需要在服务端进行翻译）。
  • 确保您的客户端与 EventHub 在同一 Azure 区域中运行。

谢谢-Eric Lam (MSFT)

于 2015-03-05T19:28:19.607 回答
0

你用什么来测量速度？您是否将数据存储在数据库中并检查是否已收到所有数据？这个问题可能在别的地方，可能在你的数据库插入中。最初尝试在分区上租用需要一些时间。预热后，您可以尝试发送更多消息。并检查是否仍然需要相同的时间。

于 2015-02-05T00:32:11.637 回答
0

增加吞吐量单位将对您有所帮助。

于 2019-01-13T07:14:20.920 回答
0

我使用了与您相同的方法，但无法接收任何事件/数据。一段时间后，我发现EventProcessorHost有点冗长，但工作得很好。

于 2016-06-12T04:21:38.820 回答