Export (0) Print
Expand All

Azure Storage Scalability and Performance Targets

Updated: May 12, 2014

This topic describes the scalability and performance topics for Microsoft Azure Storage. For a summary of other Azure limits, see Azure Subscription and Service Limits, Quotas, and Constraints.

noteNote
All storage accounts now run on the new flat network topology and support the scalability and performance targets outlined below, regardless of when they were created. For more information on the Azure Storage flat network architecture and on scalability, see the Windows Azure Storage Team Blog.

ImportantImportant
The scalability and performance targets listed here are high-end targets, but are achievable. In all cases, the request rate and bandwidth achieved by your storage account depends upon the size of objects stored, the access patterns utilized, and the type of workload your application performs. Be sure to test your service to determine whether its performance meets your requirements. If possible, avoid sudden spikes in the rate of traffic and ensure that traffic is well-distributed across partitions.

When your application reaches the limit of what a partition can handle for your workload, Azure Storage will begin to return error code 503 (Server Busy) or error code 500 (Operation Timeout) responses. When this occurs, the application should use an exponential backoff policy for retries. The exponential backoff allows the load on the partition to decrease, and to ease out spikes in traffic to that partition.

If the needs of your application exceed the scalability targets of a single storage account, you should build your application to use multiple storage accounts, and partition your data objects across those storage accounts. A single Azure subscription is allowed 20 storage accounts. If you need to store large amounts of data across multiple storage accounts, contact Windows Azure customer support. Also see Storage Pricing Details for information on volume pricing.

The scalability targets for a storage account depend on the region where it was created. The following sections outline scalability targets for US regions and for European and Asian regions.

For more details on the architecture and scalability targets for storage accounts, see the Windows Azure Storage Team Blog.

The following table describes the scalability targets for storage accounts in US regions, based on the level of redundancy chosen:

 

Total Account Capacity Total Request Rate (assuming 1KB object size) Total Bandwidth for a Geo-Redundant Storage Account Total Bandwidth for a Locally Redundant Storage Account

500 TB

Up to 20,000 entities or messages per second

*Ingress: Up to 10 gigabits per second

*Egress: Up to 20 gigabits per second

*Ingress: Up to 20 gigabits per second

*Egress: Up to 30 gigabits per second

* Ingress refers to all data (requests) being sent to a storage account.

* Egress refers to all data (responses) being received from a storage account.

The following table describes the scalability targets for storage accounts in European and Asian regions, based on the level of redundancy chosen:

 

Total Account Capacity Total Request Rate (assuming 1KB object size) Total Bandwidth for a Geo-Redundant Storage Account Total Bandwidth for a Locally Redundant Storage Account

500 TB

Up to 20,000 entities or messages per second

*Ingress: Up to 5 gigabits per second

*Egress: Up to 10 gigabits per second

*Ingress: Up to 10 gigabits per second

*Egress: Up to 15 gigabits per second

* Ingress refers to all data (requests) being sent to a storage account.

* Egress refers to all data (responses) being received from a storage account.

The following table describes the performance targets for a single partition for each service:

 

Target Throughput for Single Blob Target Throughput for Single Queue (1 KB messages) Target Throughput for Single Table Partition (1 KB entities)

Up to 60 MB per second, or up to 500 requests per second

Up to 2000 messages per second

Up to 2000 entities per second

Every object that holds data that is stored in Azure Storage (blobs, messages, and entities) belongs to a partition, and is identified by a partition key. The partition determines how Azure Storage load balances blobs, messages, and entities across servers to meet the traffic needs of those objects. The partition key is unique within the storage account and is used to locate a blob, message, or entity.

For tables, all entities with the same partition key value are grouped into the same partition and are stored on the same partition server. This is an important point to understand in designing your application. Your application should balance the scalability benefits of spreading entities across multiple partitions with the data access advantages of grouping entities in a single partition. A key advantage to grouping entities into partitions is that it's possible to perform atomic operations across entities in the same partition, since a partition exists on a single server.

Partitions affect load balancing and scalability for each of the storage services in the following ways:

  • Blobs: The partition key for a blob is container name + blob name. This means that each blob has its own partition. Blobs can therefore be distributed across many servers in order to scale out access to them. While blobs can be logically grouped in blob containers, there are no partitioning implications from this grouping.

  • Messages: The partition key for a message is the queue name, so all messages in a queue are grouped into a single partition and are served by a single server. Different queues may be processed by different servers to balance the load for however many queues a storage account may have.

  • Entities: The partition key for an entity is table name + partition key, where the partition key is the value of the required user-defined PartitionKey property for the entity.

    Entities within a table may have the same partition key values, in which case they are grouped into the same partition. An application can perform atomic batch transactions over entities within the same partition, since they are served from the same server.

    Entities that are in the same table but that belong to different partitions can be load balanced across different servers, making it possible to have a large table with greater scalability.

See Also

Show:
© 2014 Microsoft