Manu Cohen-Yashar's Blog

Windows Azure Benchmarks - Part 14: Sql Azure write throughput

2012-02-08T20:01:58Z

One of the most common questions customers ask is how does windows azure perform.
Well Microsoft published a series of benchmarks in an excellent web site called azurescope.
The thing is azurescope is going down on January 15th 2012 so I decided to publish these benchmarks here and make sure they will be available to the public.

Let us discuss Sql Azure write throughput.

This test measures the ability of SQL Azure to handle write requests from simultaneous clients.

Key Analysis

Throughput increases with the increase in number of concurrent clients (NumberOfWorkers * ThreadsPerWorker), reaches a maximum limit and then decreases with further increase in the number of concurrent clients.

Enjoy

Manu

Windows Azure Benchmarks–Part 13: Sql Azure Read throughput

2012-02-02T08:36:41Z

Let us discuss Sql Azure read throughput.

This test measures the ability of SQL Azure to handle read requests from simultaneous clients.

Key Analysis

Throughput increases with the increase in number of concurrent clients (NumberOfWorkers * ThreadsPerWorker) and saturates at a maximum value.
Bigger batch size improves throughput.
Smaller row size improves throughput.
Employing more than one thread per worker improves throughput.

Enjoy

Manu

Windows Azure Benchmarks - Part 12: Queue write latency

2012-01-31T14:34:30Z

Let us discuss queue write latency.

This test measures the write latency observed from a Windows Azure worker role instance while accessing the Windows Azure Queue Service.

Key Analysis

For message sizes upto approximately 1000 bytes, enabling Nagle decreased performance. Use ServicePointManager.UseNagleAlgorithm to turn off Nagle.
The number of pre-populated items have almost no affect on the observed latencies.

Enjoy

Manu

Windows Azure Benchmarks - Part 11: Queue read latency

2012-01-30T18:20:02Z

Let us discuss queue read latency.

This test measures the read latency observed from a Windows Azure worker role instance while accessing the Windows Azure Queue Service.

Key Analysis

The number of pre-populated items have almost no affect on the observed latencies.

Enjoy

Manu

Windows Azure Benchmarks - Part 10:Queue write throughput

2012-01-26T14:58:03Z

Let us discuss queue write throughput.

This test measures the ability of Windows Azure Queue Service to handle write requests from simultaneous clients.

Key Analysis

Throughput increases with the increase in number of concurrent clients (NumberOfWorkers * ThreadsPerWorker) and saturates at a maximum value. You may have to increase the ServicePointManager.DefaultConnectionLimit for multiple threads to establish more than 2 concurrent connections with the storage.

Enjoy

Manu

Windows Azure Benchmarks - Part 9: Queue read throughput

2012-01-25T22:24:47Z

Let us discuss Queue read throughput.

This test measures the ability of Windows Azure Queue Service to handle read requests from simultaneous clients.

Key Analysis

Throughput increases with the increase in number of concurrent clients (NumberOfWorkers * ThreadsPerWorker) upto a maximum limit after which it decreases with the increase in number of concurrent clients. You may have to increase the ServicePointManager.DefaultConnectionLimit for multiple threads to establish more than 2 concurrent connections with the storage.

Enjoy

Manu

Windows Azure Benchmarks - Part 8:Tables write latency

2012-01-24T19:46:16Z

Let us discuss tables write latency.

This test measures the write latency observed from a Windows Azure worker role instance while accessing the Windows Azure Queue Service.

Key Analysis

For message sizes upto approximately 1000 bytes, enabling Nagle decreased performance. Use ServicePointManager.UseNagleAlgorithm to turn off Nagle.
The number of pre-populated items have almost no affect on the observed latencies.

Enjoy

Manu

Windows Azure Benchmarks - Part 7: Tables read latency

2012-01-22T17:26:56Z

Let us discuss tables read latency.

This test measures the read latency observed from a Windows Azure worker role instance while accessing the Windows Azure Table Service.

Key Analysis

Using the indexed PartitionKey and RowKey columns provides lower latencies than using other columns while querying a table.
Read latencies increase linearly with the number of pre-populated items if non-key columns are used. For key columns, no significant change in latency is observed by increasing the pre-populated items.

Enjoy

Manu

SQL Azure Compatibility Assessment

2012-01-19T10:54:43Z

How do you know if your SQL database is compatible with SQL Azure and can be migrated to the cloud?

Well there is a long list of well known issues like SQL Agent and SQL CLR that are not supported, but what about those little details that no body wrote about and eventually will stop you from migrating to the cloud? It would be great if someone would tell you if migration is possible before you spend the time on a POC.

A new service was launched by the SQL Azure team for this exact reason. It is called the SQL Azure Compatibility Assessment service.
With the SQL Azure Compatibility Assessment service you can use check if your database schema is compatible with SQL Azure grammar. This service is very easy to use and does not require Azure account.

So here is what you need to do:

Generate a .dacpac file from your database using SQL Server Data Tools (SSDT) CTP4. You can either run SqlPackage.exe or import the database into an SSDT project and then build it to generate a .dacpac. SQL Server 2005, 2008, 2008 R2, 2012 (CTP or RC0) are all supported.
Upload your .dacpac to the "SQL Azure Compatibility Assessment" cloud service and receive an assessment report, which lists the schema objects that are not supported in SQL Azure and that need to be fixed prior to migration.

I recommend watching the following video

More Technical details about "SQL Azure Compatibility Assessment" tool can be found here

Enjoy

Manu

Windows Azure Benchmarks - Part 6: Tables write throughput

2012-01-18T22:28:44Z

Let us discuss tables write throughput.

This test measures the ability of Windows Azure Table Service to handle write requests from simultaneous clients.

Key Analysis

Throughput increases with the increase in number of concurrent clients (NumberOfWorkers * ThreadsPerWorker), reaches a maximum limit and then decreases with further increase in the number of concurrent clients. You may have to increase the ServicePointManager.DefaultConnectionLimit for multiple threads to establish more than 2 concurrent connections with the storage.
Using multiple partitions improves throughput when there are many concurrent clients.
Bigger batch sizes generally provide better throughput. However, if there are too many concurrent clients, smaller batches may be more performant. For example, batch size of 50 outperforms batch size of 100 for more than 21 workers.

Enjoy

Manu

Windows Azure Benchmarks - Part 5: Tables read throughput

2012-01-15T19:30:05Z

Let us discuss tables read throughput.

This test measures the ability of Windows Azure Table Service to handle read requests from simultaneous clients.

Key Analysis

Throughput increases with the increase in number of concurrent clients (NumberOfWorkers * ThreadsPerWorker) and saturates at a maximum value. You may have to increase the ServicePointManager.DefaultConnectionLimit for multiple threads to establish more than 2 concurrent connections with the storage.
CloudTableQuery sends multiple web requests with $top=100 option while using the Take clause if a value greater than 100 is passed as the argument. Consider using explicit DataServiceQuery and handle the continuation tokens if you want to send a lesser number of requests.
Partitioning occasionally shows better throughput
Bigger batch sizes generally provide better throughput.

Enjoy

Manu

Azure Elasticity with Wasabi Application Block

2012-01-11T08:53:54Z

One of the core capabilities provided by cloud computing is elasticity. It means that it is possible to provision new machines automatically when required and delete redundant instances when possible.

Unfortunately Windows Azure did not provide an easy tool-set for implementing elasticity. It was possible but it was not easy. To do that you would have to use the management API for spinning new instances together with storage REST API which was used to query the service diagnostics info.

To fill the void tools such as AzureWatch were developed yet it was weird that Microsoft does not provide its own tools and API for such fundamental cloud computing scenarios.

I am happy to announce that things changed.

Patterns and Practices announced the release of the Enterprise Library Integration Pack (wasabi) which provides a simple yet powerful ways to implement elasticity in windows azure.

With wasabi you create an application (controller) that monitors the state of your cloud services and executes actions such as create or remove instances according to predefined rules. This controller can be hosted on-premises or in the cloud. It make sense that the controller should run 24-7 to capture changes and act accordingly, so a worker role is a natural selection.

So let us write a wasabi controller:

First we create a simple worker role to host the wasabi controller.
Then we have to install the application block in our worker role. (It does much more then add references).
To do that we will use NuGet and look for "wasabi" package.

The NuGet package adds many required references to our project and adds two xml schemas we will use later to audit the rules and services xml files.

Wasabi uses information which is stored on windows Azure storage such as diagnostics info about the services to scale and rules that defines when to scale. The exact location of this info is written in the configuration of the controller application. In this case our worker's role app.config.
To configure our controller app.config we will use Enterprise library configuration tool (you can download it by searching "EnterpriseLibrary.config" in Visual Studio Gallery or by using the VS Extension Manager.

So let us right click app.config and choose "Edit Configuration File"

Now the configuration tools opens and in the Blocks menu we have to choose : AutoScaling Settings.

We can use the default configuration for now and only set the storage location for the information required by the application block.

Lets save and continue.

Now it is time to audit the services xml file.
In this file we define the location of the hosted services and roles we want to scale. We provide the management certificate details and the subscription ID that will be used by wasabi to authenticate against Azure and trigger the management commands. The management certificate must be installed on our machine so the file specifies where to find it. The subscription ID can be found in the Azure portal. It is easy to audit the xml file because its schema (AutoscalingServiceModel.xsd) was installed by NuGet.

<?xml version="1.0" encoding="utf-8" ?>
<serviceModel xmlns="http://schemas.microsoft.com/practices/2011/entlib/autoscaling/serviceModel">
  <subscriptions>
    <subscription name="ManuCohenYashar"
                  certificateStoreName="My"
                  certificateStoreLocation="CurrentUser"
                  certificateThumbprint="A7595E8F51001BA7CCB27CC6CD68E8BC05Exxxx"
                  subscriptionId="7d6af05e-632d-48aa-a957-xxxxxxxxxxxxx">
      <services>
        <service dnsPrefix="manutest" slot="Production">
          <roles>
            <role alias="WebRole1" roleName="WebRole1" wadStorageAccountName="storagelabs"/>
          </roles>
        </service>
      </services>
      <storageAccounts>
        <storageAccount alias="storagelabs" 
                        connectionString="DefaultEndpointsProtocol=https;
                                          AccountName=storagelabs;AccountKey=xxxxxx=">
          <queues>
            <queue alias="queue1" queueName ="queue1"/>
          </queues>
        </storageAccount> 
      </storageAccounts> 
    </subscription>
  </subscriptions>
</serviceModel>

The next file we have to audit is the rules file.
In this file we specify the "Business rules" according to we want to scale. (i.e. when to add an instance and when to delete one)

There are two types of rules.
Constraints rules that define a general range for the number of instances we want per role.
Proactive rules that define how to react to changes in the roles performance.
Rules can be ranked. The rules schema allows to define powerful expressions using arguments expressing countless performance attributes such as performance counters, queues length etc. (there are extensibility points here so you can define your own arguments)

<?xml version="1.0" encoding="utf-8" ?>
<rules xmlns="http://schemas.microsoft.com/practices/2011/entlib/autoscaling/rules">
  <constraintRules>
    <rule name="default" enabled="true" rank="1">
      <actions>
        <range target="WebRole1" min="2" max="4"/>
      </actions>
    </rule>
    <rule name="peek" enabled="true" rank="100">
      <timetable duration="10:00:00" startTime="08:00:00" utcOffset="2">
        <weekly days="Sunday"/>
      </timetable>
      <actions>
        <range target="WebRole1" min="20" max="40"/>
      </actions> 
    </rule>
  </constraintRules>
  <reactiveRules>
    <rule name="busy" enabled="true" rank="1">
      <when>
        <greaterOrEqual operand="cpu" than="60"/>
      </when>
      <actions>
        <scale by="1" target="webrole1"/>
      </actions>
    </rule>
    <rule name="notbusy" enabled="true" rank="1">
      <when>
        <lessOrEqual operand="cpu" than="20"/>
      </when>
      <actions>
        <scale by="-1" target="webrole1"/>
      </actions>
    </rule>
    <rule name="queueIsFull" enabled="true" rank="1">
      <when>
        <greaterOrEqual operand="queue" than="10"/>
      </when>
      <actions>
        <scale by="1" target="webrole1"/>
      </actions>
    </rule>
  </reactiveRules>
  <operands>
    <performanceCounter alias="cpu" performanceCounterName="\Proccessor(_Total\% Processor Time)" 
                        source="WebRole1" aggregate="Average" timespan="00:15:00" />
    <queueLength alias="queue" queue="queue1" aggregate="Average" timespan="00:10:00"/>
  </operands>
</rules>

The schema for this file (AutoscalingRules.xsd) was also installed by NuGet.

Now it is time to write the code within the controller (our worker role) that will activate the wasabi application block. As you can see it is very simple.

static Autoscaler autoscaler;

public override void Run()
{            
   autoscaler = EnterpriseLibraryContainer.Current.GetInstance<Autoscaler>();
   autoscaler.Start();         

   while (true)
   {
      Thread.Sleep(10000);
      Trace.WriteLine("Wasabi Controller is running", "Information");
   }
 }

The next stage is to upload the rules and services to Azure Blob Storage (to the location that was specified in the configuration tool 
and is now written in app.config)

This is it. Everything is ready.

Make sure your service (the one you want to scale) is running and is writing information to storage using Azure Diagnostics. Now deploy the controller and watch how it auto scale your service.

I created a demo solution that can be downloaded here.

I recommend watching the video at channel 9.

Enjoy

Manu

Windows Azure Benchmarks - Part 4: Blobs write latency

2012-01-09T14:51:02Z

Let us discuss blobs write latency

This test measures the write latency observed from a Windows Azure worker role instance while accessing the Windows Azure Blob Service.

Key Analysis

Block blobs show higher latencies than page blobs.
No significant change in latencies are observed up to few thousand pre-populated items.

Enjoy

Manu

Windows Azure Benchmarks - Part 3: Blob Read latency

2012-01-08T18:36:46Z

Let us discuss blobs read latency.

This test measures the read latency observed from a Windows Azure worker role instance while accessing the Windows Azure Blob Service.

Key Analysis

Block blobs show higher latencies than page blobs.
No significant change in latencies are observed up to few thousand pre-populated items.

Enjoy

Manu

Windows Azure Benchmarks - Part 2: Blob write throughput

2012-01-05T13:48:12Z

Let us discuss blobs write throughput

This test measures the ability of Windows Azure Blob Service to handle write requests from simultaneous clients.

Key Analysis

Throughput increases with the increase in number of concurrent clients (NumberOfWorkers * ThreadsPerWorker) upto a maximum of approximately 110 MBs/sec. You may have to increase the ServicePointManager.DefaultConnectionLimit for multiple threads to establish more than 2 concurrent connections with the storage.
Page blobs provide better throughput than block blobs.
For a single worker, upload throughputs upto 94 MBs/sec are observed.
Using CloudBlockBlob.PutBlock and CloudPageBlob.WritePages methods provide better throughput than writing to a BlobStream.
While writing to a BlobStream, consider setting CloudBlobClient.WriteBlockSizeInBytes to 4 MBs.
Consider using the maximum allowed block or page size of 4 MBs to write at a time while using the CloudBlockBlob.PutBlock or CloudPageBlob.WritePages to reduce server roundtrips.
Using http endpoint provides better throughput than https endpoints.

Enjoy

Manu