Skip to main content

Posts

Showing posts from October, 2014

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: Azure SQL databases Standard (S0, S1, S2) and Premium (P1, P2, P3) editions were used During all test only a single Azure SQL database existed on the server at any given time 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  Three tests were executed for each edition and number of concurrent users and the average number of transactions was calculated for the table below 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)

Azure SQL Database Performance for different editions

As of now Azure allows creating SQL Databases in three tiers - Basic, Standard, and Premium. The Basic tier has a single performance level with 5 DTU ( Database Throughput Units ) The standard tier has three levels - S0 (10 DTU), S1 (20 DTU), and S2 (50 DTU). And the Premium tier has also three levels - P1 (100 DTU), P2 (200 DTU), and P3 (800 DTU). To compare performance I created a test database in each tier and performance level. The test itself is the same as the one used in one of my previous blogs : The test was running from 5 clients for about 280 seconds and doing the following: - drop and create the test table - generate a random ID - integer within the [0, 2000000] range - if a table has no row witch such ID then insert a new row - if there is a row with such ID then update the row with the UpdateTime and a new DummyText (randomly generated length) The results clearly show that the higher DTU the more transactions per second the database can handle.