Allow consumers to save money by overriding default batching interval

[jcookems]

Consider a scenario is where you have lots of tiny messages, and the latency is not a bit issue. Then you might want to increase the batch time from 1/4 of a second to 1 minute, because messages sent to or delivered by the Service Bus are billed at $0.01 per 10,000 messages. Sending constantly every 0.25 seconds means $10 a month for sending alone, another $10 to read those messages back; batching to send every minute would reduce the cost to $0.08 total.

Another scenario where traffic is bursty; usually no traffic, then periods of an hour or so where there is a lot of traffic. A customer might want to implement a peek algorithm that polls less frequently if it gets no messages, then ramp up polling where there are messages. I don't think there is a cost benefit here, but it feels like the right thing to do.

[jcookems]

Actually, upon closer reading of the Service Bus Pricing FAQ, it looks like polling does incur a cost:

Null messages delivered by the Service Bus in response to requests against an empty queue, subscription, or message buffer, are also billable. Thus, applications that poll against Service Bus entities will effectively be charged one message per poll.

It looks like now the polling logic goes as fast as it can, one poll after another, which could cost much more than $10 a month even if nothing is happening.

[christav]

I made batch interval settable as part of the perf tester. Number of poll receivers is settable, but there's no delay interval there. Should there be?

[jcookems]

I think so, in some form. I'm thinking about a model where you want to get messages as fast as possible (current model) but only if you expect messages; otherwise poll infrequently or with fewer receivers. Something like exponential retry if there are no messages, backing off gradually, hoping there is somethjg new coming in.

however, that sort of behavior seems complex and situation dependant. It smells more like something that should be pluggable, like how the SDK supports complex retry policies in the pipeline. If you agree lets factor that issue out into a separate tracking issue.

[christav]

I agree that this sounds like a pluggable strategy, and should be a separate issue.

[glennblock]

This would be great, but I don't think it's a show stopper.

On Thu, Mar 7, 2013 at 10:29 AM, Chris Tavares [email protected]:

I agree that this sounds like a pluggable strategy, and should be a
separate issue.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/26#issuecomment-14577656
.

[christav]

Batching interval is now settable. Suggestions about polling interval covered under separate issue #39.