未加星标

Azure Functions: Choosing between queues and event hubs

字体大小 | |
[系统(windows) 所属分类 系统(windows) | 发布者 店小二05 | 时间 2018 | 作者 红领巾 ] 0人收藏点击收藏

I have this conversation about twice a week. Someone has decided they want to take advantage of the benefits of serverless Azure Functions for an upcoming project, but when starting to lay out the architecture a question pops up:

“Should we be using Azure Event Hubs, Queues, or Event Grid?”

It’s honestly a great question ― and it’s a question with consequences. Each of these messaging technologies comes with its own set of behaviors that can impact your solution. In previous blogs, I’ve spent some time explaining Event Grid , Event Hubs ordering guarantees , and how to keep Event Hub stream processes resilient . In this blog, I specifically want to tackle one other important aspect: throughput for variable workloads. Here was the scenario I was faced with this last week:

We have a solution where we drop in some thousands of records to get processed. Some records only take a few milliseconds to process, and others may take a few minutes. Right now we are pushing the messages to functions via Event Hubs and noticed some significant delays in getting all messages processed.

The problem here is subtle, but simple if you understand the behavior of each trigger. If you just have a pile of tasks that need to be completed, you likely want a queue. It’s not a perfect rule, but more often than not queues may have the behavior you are looking for. In fact, this blog will show that choosing the wrong messaging pipeline can result in an order of magnitude difference in processing time . Let’s take a look at a few reasons why.


Azure Functions: Choosing between queues and event hubs
Variability in size of eachtask

If you look at the problem posed by the customer above, one key element let me know queues could be best here.

“…Some records only take a few milliseconds to process, and others may take a few minutes.”

If I have a queue of images that need to be resized, a 100kb image will resize a lot quicker than a 100mb panoramic image. The big question is: “How does my processing pipeline respond to a long task?” It’s a bit like driving on a freeway. An incident on the road is much more impactful for a one lane road than a five lane road ― and the same is true for your serverless pipelines.

Event Hubs behavior with variability in tasktime

Azure Event Hubs cares about two things, and it does a great job with those two things: ordering and throughput. It can receive and send a huge heap of messages very quickly and will preserve order for those messages. Our team has posted previously on how Azure Event Hubs allowed us to process 100k messages a second in Azure Functions. The fact that I can consume a batch of up to 200 messages in every single function execution is a big reason for that. But those two core concerns of ordering and throughput can also get in each others way.

> If you’re not already familiar with how Event Hubs preserves order, it may be worth reading this blog on ordering first and coming back.

Imagine I have a series of events that all land in the same Event Hub partition. Let’s say my Azure Function pulls in a batch of 50 events from that partition into a function. Messages 1 9 process in a few milliseconds, but message 10 is taking a few minutes to process. What happens to events 11 50? They are stuck. Event Hubs cares about ordering, so message 10 needs to complete before message 11 starts. Imagine a scenario where the events you are receiving are stock market events ― you very much do care that a “buy” happened before a “sell” event, so you’d be glad it’s holding the line. But what if your scenario doesn’t care about ordering? What if events 11 50, or even 51 1,000 could be running while we wait for message 10 to complete? In this case Event Hubs behavior is going to slow down your performance dramatically. Event Hubs will not process the next batch in a partition until the current batch, and every event in that batch, has completed. So one bad event can hold up the entire partition.

Queues behavior with variability in tasktime

What about queues? Queues don’t care as much about ordering. Queues care more about making sure that every message gets processed and gets processed completely. Head into any government building and you will usually witness distributed queue processing in action. You have a single line of people that need something done, and a few desks of employees to help (hopefully more than one :smile:). While some employees may have requests that take a number of minutes, the other employees will keep grabbing the next person in line as soon as they are available. One long request isn’t going to stop all work from continuing. Queue triggers will be the same. Whichever instance of your app is available to take on more work will grab the next task in line. No task depends on the completion of another task in that queue.

Service Bus queues and Storagequeues

As if deciding between Event Hubs, Event Grid, and queues wasn’t hard enough, there’s a sub-decision on storage queues vs service bus queues. I’m not going to go very deep into this here. There’s a detailed doc that will lay out the big differences. In short, Service Bus is an enterprise-grade message broker with some powerful features like sessions, managed dead-letter queues, and custom policies. Storage queues are super simple, super lightweight queues as part of your storage account. I often stick with storage queues because my Azure Function already has a storage account, but if you need anything more transactional and enterprise grade (or topics), Service Bus is absolutely what you want.

Azure Functions and variable workloads

To illustrate the difference in behavior for variable workloads I ran a few tests. Here’s the experiment.

I put 1,000 identical messages in an Azure Event Hub, Azure Service Bus queue, and an Azure Storage queue. 90% of these messages would only take one second to process, but 10% (sprinkled throughout) would take ten seconds. I had three mostly identical javascript functions that I would start processing on those messages. The question is: which one would process fastest?

Experiment results: EventHubs

Shouldn’t be much of a surprise given the explanation above, but Event Hubs took roughly 8x longer than queues to process all 1,000 messages. So what happened? It actually processed about 90% of the messages by the time the queue function apps finished, but that last 10% had a very long tail. Turns out one instance got unlucky with its assigned partitions and had about 40 of those ten-second tasks. It was stuck waiting for long tasks to complete before moving on to the next set of events, which likely contained another ten-second task. The forced sequential processing for the final 10% was significant.

本文系统(windows)相关术语:三级网络技术 计算机三级网络技术 网络技术基础 计算机网络技术

代码区博客精选文章
分页:12
转载请注明
本文标题:Azure Functions: Choosing between queues and event hubs
本站链接:https://www.codesec.net/view/610827.html


1.凡CodeSecTeam转载的文章,均出自其它媒体或其他官网介绍,目的在于传递更多的信息,并不代表本站赞同其观点和其真实性负责;
2.转载的文章仅代表原创作者观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,本站对该文以及其中全部或者部分内容、文字的真实性、完整性、及时性,不作出任何保证或承若;
3.如本站转载稿涉及版权等问题,请作者及时联系本站,我们会及时处理。
登录后可拥有收藏文章、关注作者等权限...
技术大类 技术大类 | 系统(windows) | 评论(0) | 阅读(46)