Jon Bock - Development Tech Blog

In a recent programming conundrum, I was trying to find a way I could promote certain customer queries to the top of the support list compared to that of a general nature. The limitations with the azure service bus is the inability to add priority headers to packets being placed into the queue, so that was a nonstarter.

With queues, they work on a FIFO (first in first out) nature and allow developers to decouple the components that are adding items to the queue from those that are performing tasks against it.

The queue in general was great at adding items to be processed in an asynchronous nature, however with recent updates to our SLA requirements we were encountering issues where non urgent request were creating a service bottleneck in our system.

The solution that we decided to try to implement was the priority queue on the Microsoft Azure using a few message queues and multiple consumer instances against those queues.

The plan was to identify the data being processed from the producer side, and based on that generate the relevant packets and use the message router to send the packets of data to the corresponding queue. In our example, we spawn 3 types that were being used (High, Medium and Low priorities).

In essence the queue would function as normal with the producer – consumer peeking and deleting messages as they are being added to the queue. The difference and where the priority queue pattern comes into play is the number of consumers being allocated to subscribed to the particular queues. With the high priority queue, we have 5 instances competing to consumer the messages. With the medium we had 3 and with the low we had one. The result of this is that the high priority queue would be able to handle many more requests and faster than the other queues, and therefore would be able to provide a far better SLA time and meet expectations.

For more information on it you can read https://docs.microsoft.com/en-us/azure/architecture/patterns/priority-queue

You can also find the implementation example on Github

Being able to elide Async and Await can provide application efficiency benefits that at first may seem minimal but in the big picture will result in the compiler being able to skip the generation of the async state machine and result in fewer compiler generated types in the assembly as well as fewer items added to the GC and CPU computations.

When a async state machine is generated for a single await, you can effectively get a few extra IL instructions created as a result. In my opinion it is a benefit to elide await where possible but in some cases it isnt such as using statements.

Async does have great benefits such as performing code executions in parallel requests but it does however perform in a much more inefficient way than using synchronous code. Adding more awaits and async’s to an application ends up multiplying the cost at each point.

You can read more about it here:-

https://blog.stephencleary.com/2016/12/eliding-async-await.html