TL;DR: Micro-optimizations are not a substitute for design work. They are how you earn the right to redesign. In the Azure Service Bus SDK, repeated work in the Body property first led to smaller allocation fixes. Once those fixes exposed the shape of the problem, a small internal redesign made the code faster, clearer, and easier to reason about. “This code is bad. We should rewrite it.” Most developers have heard that sentence. Many have said it. I have too. The problem is not...
TL;DR: After temporary allocations were removed from the Azure Event Hubs partition-key encoding path, the Jenkins lookup3 hash loop itself became the next interesting place to look. Tightening that loop reduced CPU overhead, but it also raised the bar for review, portability, and correctness. I like performance work most when it starts with a boring question: why is this small method showing up so much? That question came up while looking at the Azure Event Hubs client. Event Hubs is built for...
TL;DR: Small code paths become expensive when cloud workloads execute them millions of times. The Azure Event Hubs partition key resolver is one of those paths. By removing temporary allocations from the partition-key encoding path, the Azure Event Hubs SDK reduced garbage collection pressure on a publishing hot path. I like performance work most when it starts with a boring question: why is this small method showing up so much? That question came up while looking at the Azure Event Hubs client...
Explains how de-duplication can help to make sure a message is only delivered once within a certain time period, for more posts in this series go to Contents. In the posts atomic sends and send via I showed ways to achieve atomicity for a group of messages or messages that are sent out as part of an outgoing message. Let’s have a look at a piece of code that looks super simply but might always behave like you’d wish it should behave: public async Task<IActionResult>...
Explains how message sessions can be used to de-multiplex interleaved message streams and guaranteed ordered delivery, for more posts in this series go to Contents. Usually, when someone asks what the characteristics of a queue is most people would say First-in, first out. The thing is though with regular Azure Service Bus queues that is not guaranteed. Simply because you might do concurrent receive operations on the same queue or a message that failed processing will be handled later due to...
Explains where messages go when they can’t be transferred to the destination, for more posts in this series go to Contents. A while ago, I introduced the concept of deadlettering messages in which I talked about where messages go in case of message expiry, reaching the maximum delivery count, or they were forcefully dead lettered. In the posts about atomic sends as well as send via, I showed how a transaction scope can be used to group send operations together into atomic units that...
Shows how to query runtime information using the management client, for more posts in this series go to Contents. Quite early in this series I introduced the ServiceBusAdministrationClient to create queues for example. Besides being able to create entities like queues, topics and subscriptions, the administration client provides the capability of querying runtime information from namespaces, queues, topics and subscriptions. The ability to query runtime information is quite handy for...
With SendVia, it is possible to create an atomic transaction between the incoming message and outgoing messages, for more posts in this series go to Contents. In scenarios where transactional processing is required for an incoming message that would generate some outgoing messages, the incoming and outgoing messages should all succeed or rollback. Failure to do so would either create duplicate processing (failure to complete the incoming message) or ghost messages (failure to revert the...
Shows how to batch multiple messages together into one single operation against Azure Service Bus, for more posts in this series go to Contents. In the article about atomic sends, we talked about the fact that each send operation executed against Azure Service Bus can fail and potentially has to be retried. Another important aspect though that wasn’t covered in the previous article is that every send operation has latency costs associated with it. Let’s assume we want to send ten...
Shows how to atomically send messages as a group, for more posts in this series go to Contents. This topic is best illustrated by directly diving into some code. await using var sender = serviceBusClient.CreateSender(destination); var message = new ServiceBusMessage("Deep Dive 1"); await client.SendMessageAsync(message); message = new ServiceBusMessage("Deep Dive 2"); await client.SendMessageAsync(message); In the above code, a QueueClient is used to send two messages. By default, every time...