11

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. enter image description here

Aatif Akhter
  • 2,126
  • 1
  • 25
  • 46
chindirala sampath kumar
  • 591
  • 5
  • 16

2 Answers2

5

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.

snow_FFFFFF
  • 3,235
  • 17
  • 29
  • Thanks for your reply. It gave me clarity on this issue. – chindirala sampath kumar Oct 14 '16 at 07:06
  • 13
    But I don't understand the difference between requests and messages.. – naman1994 Nov 18 '19 at 09:02
  • Are you able to help with this question? https://stackoverflow.com/questions/67101657/azure-service-bus-topic-requests-vs-messages/ – David Klempfner Apr 15 '21 at 05:10
  • 2
    What is the difference between requests and messages...? Others have asked as well! And do they have anything to do with "Operations"? – iBobb May 05 '21 at 09:19
  • 2
    It is odd that the graph above shows "requests" and "messages", but the azure billing information talks about operations. To me, a request would be an operation - so any API call to the service. Any given message (your actual payload) may involve multiple operations, as described above. Of course, this is just my interpretation (I don't work for Microsoft). – snow_FFFFFF May 05 '21 at 17:12
1

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.

cryss
  • 4,130
  • 1
  • 29
  • 34