0
votes

We are using EventHubSender.Send and EventHubSender.SendBatch API methods to send data packets on Azure Event Hub. Each data packet is typically of 6KB in size and there are 13 such data packets every second from 13 different client machines (Each machine sends one data packet every second). We have two event hubs in single namespace each with [6 KB * 13] packets as ingress and egress. Since the total ingress and egress is much lower than the capacity of one Throughput Unit, there is no throttling observed.

However, the send latency does not remain consistent for packets sent every second. Sometimes the send latency goes as high as 3 to 4 seconds. This behaviour was tested for on-premise client machines as well as client machines in Azure data-centre (only for testing purpose).

Client Initialization code snippet:

var factory = MessagingFactory.CreateFromConnectionString(EventHubConnectionString);
EventHubClient eventHubClient = this.factory.CreateEventHubClient(EventHubName);
this.eventHubSender = eventHubClient.CreatePartitionedSender(EventHubPartitionId);

The sender code snippet:

using (EventData eventData = CreateEventDataPacket(data, settings))
{
      this.eventHubSender.Send(eventData);
} 

Please note: The eventHubSender instance is being reused for every subsequent send request and the transport type used in EventHubConnectionString is AMQP.

Please suggest if the latency can be reduced and made consistent for both Send and SendBatch methods.

1

1 Answers

0
votes

You are creating PartitionedSender which sends event to a specific partition. On the service side, partition might move from one backend to another when performing service upgrade, which will make partition unavailable for couple seconds and might contribute to the send latency. If you do not use partitionedSender, event hub client will send to each partition round-robin way which should mitigate the situation when partitions are moved.

Besides that, send latency is also subject to many factors such as network, load balancing, service availability etc.