Skip to main content

Azure SQL Database Scalability for IO and CPU bound scenarios

In the previous post I ran the test with 5 concurrent clients and in this post I present results fgenerated by the same test but executed with different numbers of concurrent users:


  1. Azure SQL databases Standard (S0, S1, S2) and Premium (P1, P2, P3) editions were used
  2. During all test only a single Azure SQL database existed on the server at any given time
  3. The tests were executed for 200 seconds with 1,2,3,5, and 10 concurrent clients and after completion the test for a given number of the concurrent users all tables were dropped and re-created 
  4. Three tests were executed for each edition and number of concurrent users and the average number of transactions was calculated for the table below
  5. After completion the tests against a particular database edition the database was dropped and a new one was created in the next edition and/or tier (e.g., when all 5 tests have been completed against the S0 database that database was dropped and a new one was created in the S1 edition/tier)


The results are presented in this table:


The chart below shows the number of transactions reported for each database performance level and number of concurrent clients



The results show that Azure databases in the Standard edition (for any performance level - S0, S1, and S2) reach their maximum numbers of IO's (as it's defined by Microsoft for each of the levels) with a single client (because the test generates lot's of INSERT/UPDATE operations).

For the Premium edition adding concurrent users does increase the overall performance but only level P3 demonstrates ability to scale up to 10 clients for the given performance test (I did run the test with 15 concurrent users and for level P3 the results were only marginally better by 2.5-2.8 %).

Thus, if your application is IO bound and must handle multiple concurrent active connections then run your tests to choose the database edition and performance level than would meet your needs.

To test how well the Azure SQL databases are able to handle CPU bound load I used this test - calculate 200,000 times SHA-512 hash value for a 1280-byte string.
The results shows that the performance levels at the Premium edition seem to have identical internal cap on CPU usage but for the standard edition the maximum CPU utilization allowed per connection is actively throttled.



Comments

Popular posts from this blog

Create 3-Node Windows 2012 Multi-subnet Cluster

Environment There are two Data centers connected via a WAN link. Two Windows 2012 Servers (called SQLDEV1 and SQLDEV2) are located in the Primary Data Center (on the IP subnet 192.168.79.0/24) and the third server is placed in the Secondary Data Center with the 192.168.69.0/24 subnet. We’ll be creating a three-node Windows cluster with no shared storage on the multi subnet network with a file share witness at the Primary Data Center. We’ll be using a file share witness to protect from the cluster failure in a situation when the network between the Data Centers is unavailable and one of the servers in the Primary Data Center is also down (or being rebooted). The final state will look like depicted above: -           Two Virtual IP’s will be assigned (192.168.76.218 and 192.168.69.134) to the cluster -           The servers at the Primary Data Center will have a vote (Vote=1) and the ...

SQL 2014 performance - Local disk vs. Azure Blob vs. Azure VM attached disk

Today I decided to compare SQL 2014 (RTM) performance when running a test against  - a local database (created on  WD7500BPKT - 750 GB 7200 RPM)  - a DB created on a disk attached to the A3 (3 cores, 7 GB) VM in Azure - a DB created on an Azure blob The VM in Azure was created in the US East region using the SQL 2014 template from the gallary provided by Microsoft. All databases were created with a single 10 GB data file (10 GB) and 1GB  log file. On the local SQL instance the DB was created as CREATE DATABASE TestDBonLocal ON     (NAME = file_data1, FILENAME = 'C:\TEMP\filedata1.mdf', SIZE = 10GB, FILEGROWTH = 256 MB )  LOG ON  (NAME = file_log1, FILENAME = 'C:\TEMP\filelog1.ldf', SIZE = 1GB, FILEGROWTH = 32 MB)  On the Azure VM the database on the attached disk (the disk was mapped as drive F:) was created as such CREATE DATABASE TestDBonDisk ON     (NAME = file_data1, FILENAME = 'F:\TMP\filedat...

SQL 2012 AlwaysOn: Synchronous vs. Asynchronous commit. Performance impact

Recently I've had a chance to build a 3-server AlwaysOn environment distributed between the primary and secondary data centers. The configuration looks like this: Primary Data Center                         Secondary Data Center                        SQLDEV1                                        SQLDEV3          SQLDEV2 The availability group was crated with synchronous commit replicas on SQLDEV1 and SQLDEV2 and the replica on SQLDEV3 was configured for asynchronous commit. The link between the data centers was not great and when I pinged SQLDEV3 from SQLDEV1 I got these results Approximate round trip times in milli-seconds:     Minimum = 39ms, Maximum = 63ms, Average = 42ms I also created a very simp...