Azure Event Hub / Service Bus Performance - Http Batch Send 2

After the previous post on Http Batch send for Service Bus I received some emails with questions. I looked at the msdn documentation for both Service Bus and Event Hub and noted they are missing some information. Event Hub documentation does not even mention Batch Send. So here is another post about Batch Send.

Does Event Hub support batch send?

YES!

Azure Event Hub was developed by Microsoft to support IoT scenarios. It was written by the same team that owns Azure Service Bus (that is why it’s under the Service Bus Namespace) so they share a big part of their codebase. As a matter of fact I worked on the Batch Send feature to improve the throughput of the Http code path for Eventhub. But as we were working on it we made sure it was working for Service Bus as well.

Since I’m serializing as JSON do I need to change something in the Receive?

Nothing changes in the receive path. Json is only used to create the batches of messages, but in the receive code path we will be receiving them separately. The batch is gone by then.

Can you show a few samples on how to send different payloads?

Like I said in my previous post this is the format for an Http Message:

  You don’t need to send the fields that you don’t use. So if you are only sending a text payload you can just send a message like this:

  This is equivalent to the Non-Batch Http Send. The receive code path does not change. You would just receive it like you would receive a regular text message (no need to deserialize, we default to text serialization).

However in the past you have been able to set some Broker Properties in your Http message (such as CorrelationId, SessionId, PartitionKey, TimeToLiveTimeSpan, etc) and we still support that. You can just set those as part of the BrokerProperties Dictionary and we will set them in the BrokeredMessage.

And again if you want to set your own Properties you can add them to the UserProperties Dictionary and we will populate the BrokeredMessage.Properties with them

And finally if you want to send an arbitrary object instead of plain text you can do it by using the IsBodyBase64 setting.

Here is an example of sending an object of a custom class called MyTestObject.

1)

2)

3)

As you can see we do the following:

• Define the class of our custom object
• We create a new object of this class
• We JsonifyTheObject (This creates the message that we will insert into a batch)

- Use BinaryFormatter (from System.Runtime.Serialization) to serialize our object.
- Convert that to a Base64 Encoded string (This is the body)
- Create an HttpBrokeredMessage that has this newly created body
- Serialize this to Json with NewtonSoft.JsonConvert

• Now we have a json string that contains one message. We can do the same with the rest of our messages and send them as a Json array “[message1, message2…]”

Now the interesting thing of sending binary messages is that when we are receiving them we can just do a Receive<MyTestObject> and the .Net client will do all the hard work of deserialization for you. So the code in the receive path is a lot simpler :)

Accepted types for UserProperties

We accept the same types used for regular Rest Send:

· Boolean values

· Null

· Integers

· Doubles

· Strings

Sample receive code

 The receive code path has not changed at all. From the .Net client you can just do a Receive and get back your message. From Http you can use code similar to this:

For Text:

For Binary objects:

}

How to debug any problems with Batch Send?

1)      If when you receive the message you receive one IEnumerable object with n elements in it that means you are not going through the Batch Send pipeline. Double check if the Request content type is correct. It should be "application/vnd.microsoft.servicebus.json"

2)      If you get a 400 error when you send then that means something is wrong with your message. You can use this code to get more information from the web exception: