I'm new to azure event grid concepts and currently doing research on event grid to implement in our project. Can any one tell about the throughput of event grid, how many events I can push per second and what is the egress of event grid per second, means count of output events per second from event grid.
-
It seems you're looking for Event Hubs. Care to share why would you pick Grid instead? – evilSnobu Feb 02 '18 at 07:42
-
@evilSnobu We have already started using Event hub by integrating with azure functions.But,Since the Event Grid has the Retry capability, we hope it will match our current requirement(need to retry sending notification until it succeed.) – k11k2 Feb 02 '18 at 08:04
-
What kind of notifications, and to what target? You'd usually throw in Notification Hubs if a human is supposed to get those. – evilSnobu Feb 02 '18 at 08:08
-
@k11k2, Scalability of the Event Grid: Capable of routing 10,000,000 events per second per region. https://learn.microsoft.com/en-us/azure/iot-hub/iot-hub-event-grid-routing-comparison – Roman Kiss Feb 02 '18 at 09:45
-
@evilSnobu We send SMS notifications to users based on their request (to notify their profile updates, account details etc) & Yes we are currently throwing events to event hub, and triggering the event hub with azf to process the event and send to user.Bt in some cases while processing at any point of time due to request rate large exceptions, or connection problems process notification fails.Inorder to retry processing the event we have implemented our own failure mechanism.Bt this is becoming another functional challenge to handle, that is the reason why we are trying to switch to Event grid – k11k2 Feb 02 '18 at 09:50
-
@RomanKiss Thanks for the update, but can we configure the number of events that we can push to the Event handler per second i.e, in our case azure function. For example we have configured `maxBatchSize` from event hub to the event hub trigger as 30 like wise can we configure for event gird in azure account. – k11k2 Feb 02 '18 at 10:00
-
If you're failing processing on the consuming side just switch to Service Bus or Service Bus Premium for high throughput. This will give you server side cursor and a proper queue rather than distributed logging (Event Hubs). Retry logic is built into Functions SDK for Service Bus trigger. If the message fails processing it will return to the queue and retried later. – evilSnobu Feb 02 '18 at 11:16
-
@evilSnobu any reason for not to use Event Grid ? cause need to carry those concerns to our high authority. – k11k2 Feb 02 '18 at 12:00
-
@evilSnobu as you said I gone through it. `System.Threading.Thread.Sleep(policy.RetryInterval);` But I think making the thread to sleep for the retry interval is not a feasible solution. Is there any better way to handle the retry logic in service bus trigger? – k11k2 Feb 02 '18 at 15:20
-
You do not have to handle it yourself, it's baked into the runtime (WebJobs SDK Script). Your Azure Function is doing a PeekLock, so simply write your consumer as if nothing bad can happen, see this - https://learn.microsoft.com/en-us/azure/azure-functions/functions-bindings-service-bus#trigger---peeklock-behavior – evilSnobu Feb 02 '18 at 15:26
-
@k11k2, The AEG represents a real-time eventing Pub/Sub model with a scalable reliable delivery events to the subscribers (destination entity - event sink). The AEG default design is based on PushWithAck delivery events to the event sink, but subscribing an Azure Event Hub to the AEG, we can easy extended this evening model for streaming and for "pull delivery" events by event sink. – Roman Kiss Feb 02 '18 at 16:52
2 Answers
Event Grid is build for large scale - millions of events per second in on throughput for both ingress and egress: https://learn.microsoft.com/en-us/azure/event-grid/overview#capabilities
There isn't a concept of a namespace in Event Grid, so you don't pre-provision a certain throughput capacity. It scales as you use it on a pay-per-operation basis.

- 312
- 1
- 7
I asked Microsoft about this topic and this was their response:
Nape: Publish rate limit is about 5000 events per second. This is the events you can publish to Event Grid. You can achieve rates higher than this if the service instance is not as loaded. Keep in mind EG is a multitenant system.
https://learn.microsoft.com/en-us/azure/iot-hub/iot-hub-event-grid-routing-comparison High: Capable of routing 10,000,000 events per second per region.
Above represents the capability of the entire service in dispatching events, per region.

- 51
- 4
-
110 million capability is for IoT Hub. 5000 events is limit for Event Topics / Event Domains, based on what resource your are creating. – Anoop Feb 03 '20 at 04:36