Objective review
Answer the following questions to test your knowledge of the information in this objective.
You can find the answers to these questions and explanations of why each answer choice is correct or incorrect in the “Answers” section at the end of this chapter.
1. Which of the following statements are true of Service Bus relays? (Choose all that apply.) A. WCF is required for implementing server-side listeners to a relay.
B. Relays can help avoid communication issues by using port 80 or 443.
C. Relays have a limited number of client and listener connections.
D. Relays do not support any inbound communications.
2. Which of the following statements are true of queues and topics? (Choose all that apply.) A. Service Bus queues can provide an alternative strategy to relays for communicating
with on-premises resources.
B. Both queues and topics can be used in publish and subscribe messaging imple- mentations.
C. To disable processing for Service Bus queues, topics, or event hubs, you must remove the entity from the subscription.
D. Both queues and topics rely on partitions to increase throughput.
3. Which of the following statements about event hubs are true? (Choose all that apply.) A. Event hubs do not support TTL for messages. Messages are deleted as soon as they
are consumed.
B. Event hubs provide a dead-letter queue for messages that cannot be processed.
C. Event hubs support processing messages multiple times until they expire.
D. Event hubs, like queues and topics, support sending and receiving messages in batches.
Objective 5.5: Scale and monitor communication
In this section, you learn how to choose a Service Bus pricing tier, scale Service Bus features, and monitor communication.
This objective covers how to:
■
■ Choose a pricing tier
■
■ Scale Service Bus
■
■ Monitor Service Bus relays, queues, topics, event hubs, and notification hubs
Choosing a pricing tier
The Service Bus has two types of tiers: a messaging tier for brokered messaging entities and a notification hubs tier. When you create a Service Bus namespace, you choose a messaging tier for all entities that will belong to that namespace. The tier you choose controls which entities you have access to as follows:
■
■ Basic tier Queues and event hubs (up to 100 connections)
■
■ Standard tier Queues, event hubs, topics, and relays (up to 1000 connections) Standard tier also supports advance brokered messaging features such as transactions, de-duplication, sessions, and forwarding, so if you need these features for your solution, select the standard tier.
MORE INFO SERVICE BUS TIERS
For information on Service Bus tier pricing, see http://azure.microsoft.com/en-us/pricing/
details/service-bus/.
Specifically related to event hubs, the basic tier only supports a single consumer group, so if you want to support parallelized processing across partitions, choose standard messaging tier. In addition, standard tier provides additional storage up to seven days for event hubs.
MORE INFO EVENT HUB TIERS
For information on event hub tier pricing, see http://azure.microsoft.com/en-us/pricing/
details/event-hubs/.
Notification hubs have a separate tier selection strategy outside of the namespace tier.
When you create a namespace that supports notification hubs, you choose a messaging tier for brokered messaging entities, if applicable, and select a notification hub tier appropriate to your expected push notification strategy. All tiers support unlimited devices, but there are some differences between the tiers:
■
■ Free tier Up to 1 million messages per month; no support for auto-scale nor a number of other enterprise features
■
■ Basic tier 10 million messages per month plus unlimited overage for a fee; support for auto-scale; no support for other enterprise features
■
■ Standard tier The same as basic tier with all enterprise features
MORE INFO NOTIFICATION HUB TIERS
For information on notification hub tier pricing, see http://azure.microsoft.com/en-us/
pricing/details/notification-hubs/.
Objective 5.5: Scale and monitor communication CHAPTER 5 371
Scaling Service Bus features
Service Bus entities scale based on a variety of properties, including
■
■ Namespaces
■
■ Partitions
■
■ Message size
■
■ Throughput units
■
■ Entity instances
Not all of these properties impact every Service Bus entity in the same manner.
A Service Bus namespace is a container for one or more entities, such as relays, queues, topics, event hubs, and notification hubs. In most cases, the namespace itself is not a unit of scale, with some exceptions specifically related to pricing (referenced earlier), event hub throughput (to be discussed), and the following:
■
■ For relays, there is a limit to the number of endpoints, connections overall, and listeners.
■
■ The number of topics and queues are limited, and separately a smaller number of partitioned topics and queues are supported.
Since pricing is not directly related to namespace allocation between relays, queues, topics, and event hubs, you can avoid reaching some of these limits by isolating entities that could be impacted into separate namespaces. For example, consider isolating individual relays that might grow their connection requirements, or consider isolating partitioned queues and topics.
MORE INFO SERVICE BUS QUOTAS
For the latest information related to namespace and other quotas for individual Service Bus entities, see http://msdn.microsoft.com/en-us/library/azure/ee732538.aspx.
Beyond namespace selection, each entity has slightly different requirements for scale as is discussed in this section.
Scaling relays
This section discusses how to scale relays for potential namespace limitations.
NAMESPACE
As mentioned previously, relay endpoints have a limited number of overall connections and listeners that can be supported per namespace. When you are considering the design for a relay service, you should consider the number of concurrent connections that might be required for communicating with the endpoint.
If the scale of the solution has the potential to exceed the quota per namespace, the following approach can help to mitigate the limitation:
■
■ Design the solution to support publishing an instance of each relay service into mul- tiple namespaces. This will allow for growth so that additional listeners can be added by adding namespaces with a new relay service instance.
■
■ Design the solution so that clients sending messages to the relay service can distribute calls across a selection of service instances. This implies building a service registry.
EXAM TIP
Relay services can be replaced with queues or topics to provide greater throughput, scal- ability, and design flexibility.
Scaling queues and topics
This section discusses how to scale queues and topics for potential namespace or storage limitations and discusses the use of batching and partitions to help with scaling.
NAMESPACE
Queues and topics are similar in their scale triggers. Neither is particularly bound by the namespace it belongs to except in the total number of queues or topics supported and the limited number of partitioned queues and topics. Ideally, you will have a pattern for your solution in terms of namespace allocations by Service Bus entities.
STORAGE
When you create a new queue or topic, you must choose the maximum expected storage from 1 GB to 5 GB, and this cannot be resized. This impacts the amount of concurrent storage supported as messages flow through Service Bus.
BATCHING
To increase throughput for a queue or topic, you can have senders batch messages to Service Bus and listeners batch receive or pre-fetch from Service Bus. This increases overall through- put across all connected senders and listeners and can help reduce the number of messages taking up storage.
MORE INFO BATCHING AND PRE-FETCHING
For more information on batch send, batch receive, or pre-fetch, see http://msdn.microsoft.
com/en-us/library/azure/hh528527.aspx.
PARTITIONS
Adding partitions increases the number of message brokers available for incoming messages, as well as the number available for consuming messages. For high throughput queues and topics, you should enable partitioning when you create the queue or topic.
Objective 5.5: Scale and monitor communication CHAPTER 5 373 MORE INFO PARTITIONED ENTITIES
For more information on partitions, see http://msdn.microsoft.com/en-us/library/azure/
dn520246.aspx.
Scaling event hubs
This section discusses how to scale event hubs for potential namespace limitations and discusses how to set throughput units or use partitions to help with scaling.
NAMESPACE
Each namespace can have multiple event hubs, but those event hubs share the throughput units allocated to the namespace. This means that multiple event hubs can share a single throughput unit to conserve cost, but conversely, if a single event hub has the potential of scaling beyond the available throughput units for a namespace, you might consider creating a separate namespace for it.
EXAM TIP
You can request additional throughput units for a namespace by calling Microsoft support.
THROUGHPUT UNITS
The primary unit of scale for event hubs is throughput units. This value is controlled at the namespace level and thus applies to all event hubs in the namespace. By default, you get a single throughput unit which provides ingress up to 1 MB per second, or 1,000 events per second, and egress up to 2 MB per second. You pre-purchase units and can by default configure up to 20 units.
PARTITIONS
A single event hub partition can scale to a single throughput unit; therefore, the number of partitions across event hubs in the namespace should be equal to or greater than the number of throughput units selected.
Scaling notification hubs
You can scale push notifications through notification hubs to millions of devices if you choose basic or standard tier. With basic or standard tier, you can push an unlimited number of notifi- cations, but the fees per notification will vary between these two tiers.
Monitoring Service Bus features
In this section you learn how to monitor queues, topics, event hubs, and notification hubs.
MORE INFO SERVICE BUS EXPLORER
Service Bus Explorer is a tool used for managing and monitoring Service Bus features such as queues, topics, relays, and notification hubs. While you can use the management portal to monitor basic communication statistics, this tool can provide additional insights. For tu- torials and to access the source code, see https://code.msdn.microsoft.com/windowsazure/
Service-Bus-Explorer-f2abca5a.
Monitoring queues
To monitor a Service Bus queue from the existing portal, complete the following steps:
1. Navigate to the Dashboard tab for the queue, where metrics are presented in a graph (see Figure 5-22).
FIGURE 5-22 The metrics graph shown on the Dashboard tab for a queue
2. You can show relative or absolute values by selecting from the drop-down list above the graph (click the down arrow beside the word Relative shown in Figure 5-22).
3. You can choose the number of hours or days to include based on a predefined list shown in the drop-down list above the graph (click the down arrow beside 1 Hour shown in Figure 5-22).
It is useful to compare the number of incoming and outgoing messages to note any behavior that indicates burst activities for messages received or reduced ability to process requests as they are received. In addition, you can monitor queue length to note increases indicating requests not yet processed.
Monitoring topics
To monitor a Service Bus topic from the existing portal, complete the following steps:
1. Navigate to the Monitor tab for the topic, where metrics are presented in a graph (see Figure 5-23).
Objective 5.5: Scale and monitor communication CHAPTER 5 375 FIGURE 5-23 The metrics graph presented on the Monitor tab for a topic
2. Click Add Metrics on the command bar to choose from a list of metrics, including topic or specific subscription metrics. After selecting additional metrics to monitor, you will be able to filter which metrics to show in the graph.
As describedw in the previous section for queues, you can show relative or absolute values in the graph, and you can choose the number of hours or days to include based on a pre- defined list.
As with queues, it is useful to compare the number of incoming and outgoing messages to note any behavior that indicates burst activities for messages received or reduced ability to process requests as they are received across all subscriptions in aggregate. In addition, moni- tor the length of each subscription to look for problems with throughput to those endpoints.
Monitoring event hubs
To monitor a Service Bus event hub from the existing portal, navigate to the Dashboard tab for the event hub, where metrics are presented in a graph.
FIGURE 5-24 The metrics graph presented on the Dashboard tab for an event hub
As described in the previous section for queues, you can show relative or absolute val- ues in the graph, and you can choose the number of hours or days to include based on a predefined list.
It is useful to compare the number of incoming and outgoing messages to note any behavior that indicates burst activities for messages received or reduced ability to process requests as they are received. You can also monitor incoming and outgoing throughput to measure throughput usage of this event hub for ingress and egress. Again, you are typically looking for bursts or decreases in usage indicating a need to adjust scale.
Monitoring notification hubs
To monitor a Service Bus notification hub from the existing portal:
1. Navigate to the Monitor tab for the notification hub, where metrics are presented in a graph.
2. You can show relative or absolute values, and you can choose the number of hours or days to include based on a predefined list.
3. Click Add Metrics on the command bar to choose from a list of metrics, including platform-specific metrics across each respective notification service and additional metrics for notification hub messaging (see Figure 5-25).
FIGURE 5-25 The Choose Metrics dialog box for selecting notification hub metrics to monitor It is useful to monitor registration operations to note when there are bursts or decreases in those requests. In addition, monitoring errors for each platform notification service might help you identify specific issues related to that platform.
Objective 5.5: Scale and monitor communication CHAPTER 5 377
Thought experiment Scaling Service Bus
In this thought experiment, apply what you’ve learned about this objective. You can find answers to these questions in the “Answers” section at the end of this chapter.
You are designing a solution that will include Service Bus queues and event hubs.
Queues will be used for asynchronous requests to generate reports and email them to customers on a monthly basis. You will have a peak period at the end of the month during the last week, and the rest of the month, requests will be sporadic and unpredictable. Reports are used to summarize data that is analyzed by the system. The data is diagnostic data sent by devices (IoT) through event hubs to your servers. The number of devices and amount of data collected is expected to grow.
1. What more do you need to know about this scenario to determine a scaling strategy?
2. How will you choose a messaging tier and namespace allocation?
3. How will you approach optimizing queue throughput?
4. How will you approach optimizing event hub throughput?
Objective summary
■
■ Service Bus pricing tiers fall into a few categories: a Service Bus messaging tier, an event hub tier, and a notification hub tier.
■
■ Relay services are primarily scaled by adding namespaces and listeners for processing messages.
■
■ Queues and topics are primarily scaled by choosing a larger storage size, adding partitions, and batching messages on both send and receive.
■
■ Notification hubs are scaled by adjusting the tier to allow for increased message volume.
■
■ You can monitor queues, topics, event hubs, and notification hubs in the existing management portal.
Objective review
Answer the following questions to test your knowledge of the information in this objective.
You can find the answers to these questions and explanations of why each answer choice is correct or incorrect in the “Answers” section at the end of this chapter.
1. Which of the following are valid statements about choosing a pricing tier for Service Bus? (Choose all that apply.)
A. Relays are supported in basic or standard messaging tier.
B. Event hubs are only supported in standard messaging tier.
C. Standard messaging tier is limited to 1,000 connections.
D. Notification hub tiers all support unlimited messaging, but the price varies.
E. Free messaging tier only supports queues and topics.
2. Which of the following statements about scaling Service Bus are true? (Choose all that apply.) A. Allocating relays to individual namespaces improves scalability per relay.
B. Increasing queue and topic partitions improves capacity to process messages at the server.
C. Event hubs scale with paid throughput units.
D. Notification hubs scale to more devices by adding namespaces.
3. Which of the following statements about monitoring Service Bus entities in the management portal are true? (Choose all that apply.)
A. You can monitor incoming and outgoing messages for queues, topics, and event hubs.
B. You can monitor ingress and egress for topics and event hubs.
C. Monitoring queue and topic length can indicate issues with throughput.
D. Monitoring notification hubs by device can help isolate issues local to a device.