Menu
Our Application is using Azure service bus for messaging purpose. We created few topics and subscribers. We will send around 500 messages per day, but in the graph it shows hundreds of thousands of requests for 500 messages. Our billing price is also around 800$ per month. This is too much for 500 * 30 messages. I am not able to understand why the price is this much and also I want to know what does the requests in the graph mean?.
If the reason for the price is because of number of requests then how can I reduce the number of requests?. Messages I am seeing correctly. The problem is only with requests.
This is Just a sample Graph for your reference(Not original). In original graph I see around 100k of requests for 500 messages.
611
Service Bus Premium Messaging provides resource isolation at the CPU and memory level so that each customer workload runs in isolation. This resource container is called a messaging unit.
Azure Service Bus is a fully managed enterprise message broker with message queues and publish-subscribe topics (in a namespace). Service Bus is used to decouple applications and services from each other, providing the following benefits: Load-balancing work across competing workers.
Messaging services on Azure provide the interconnectivity between components and applications that are written in different languages and hosted in the same cloud, multiple clouds, or on-premises.
Here, under FAQ: https://azure.microsoft.com/en-us/pricing/details/service-bus/
How is the Operations meter calculated for queues and topics?
For brokered entities (queues and topics/subscriptions), an operation is any API interaction with Service Bus service on any protocol.
A send, receive delete for a message that is less than or equal to 64KB in size is considered as one billable operation. If the message is greater than 64KB in size, the number of billable operations is calculated according to the message size in multiples of 64KB. For example, an 8 KB message sent to the Service Bus will be billed as one operation, but a 96 KB message sent to the Service Bus will be billed as two operations. Reading the 8KB message with a lock and then completing or explicitly abandoning the message will be billed as two operations. Renewing the lock on a message also incurs an operation.
Multiple deliveries of the same message (for example, message fan out to multiple subscribers or message retrieval after abandon, deferral, or dead lettering) will be counted as independent operations. For example, in the case of a topic with three subscriptions, a single 64KB message sent and subsequently received will generate four billable operations, one “in” plus three “out”, assuming all messages are delivered to all subscriptions and deleted during the read.
Additionally creating, reading (listing), updating and deleting a queue, topic or subscription will each incur an operation charge.
Operations are API calls made against queue or topic/subscription service endpoints. This includes Management, Send/Receive and Session State Operations.
59
This is what I found in the docs, but not fully sure if that's what you were looking for:
When creating a queue or subscription client, you can specify a receive mode: Peek-lock or Receive and Delete. The default receive mode is PeekLock. When operating in the default mode, the client sends a request to receive a message from Service Bus. After the client has received the message, it sends a request to complete the message.
When setting the receive mode to ReceiveAndDelete, both steps are combined in a single request. These steps reduce the overall number of operations, and can improve the overall message throughput. This performance gain comes at the risk of losing messages.
44
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
