パフォーマンス向上が行われましたので、SQL Database の新しいエディションの特性を調べてみる (2014/7 版) を投稿しました。
最新の情報はこちらをご覧ください。
現在はプレビューですが、SQL Database で新しく、Basic / Standard エディションが提供され、各エディションに応じてパフォーマンスレベルが設定され、今までは Premium を除くとベストエフォートだったものがパフォーマンス目標がたてられるようになりました。
Azure SQL Database Service Tiers and Performance Levels
これにより、各エディションに応じてトランザクションレートが異なってきます。
今まではスケールアウトが性能を伸ばす方法だったかと思いますが、エディションとパフォーマンスレベルを変更することにより、スケールアップができるようになったようですね。
Azure SQL Database Service Tiers (Editions)
DTU については、Azure SQL Database Service Tiers and Performance Levels に記載されている以下の記述になるかと。具体的な値については記載されていないようですね。
Database Throughput Unit (DTU): The resources powering each performance level are represented in DTUs. It combines CPU, memory, physical reads, and transaction log writes into a single unit. A performance level with 5 DTUs has five times more power than a performance level with 1 DTU.
新しいエディションでは料金体系も変更になり、今までのデータベースの実際の使用量から、エディション / パフォーマンスレベルに応じた課金体系となるようです。
■性能特性を調べてみる
それでは本題に入ってみます。
以下のように複数のデータベースを作成して性能特性を見てみたいと思います。
今回、性能特性を見るために使うクエリは以下になります。
テスト用のテーブルを作成し、5,000 件の INSERT をして、待ち事象を確認するというものになります。
<br />SET NOCOUNT ON <br />GO <br />CREATE TABLE Table_1 <br />( <br />c1 uniqueidentifier, <br />c2 char(1000), <br />CONSTRAINT PK_Table_1 PRIMARY KEY (c1) <br />) <br />GO <br />SELECT * FROM sys.dm_db_wait_stats ORDER BY wait_type ASC <br />GO <br />INSERT INTO Table_1 VALUES(NEWID(), NEWID()) <br />GO 5000 <br />SELECT * FROM sys.dm_db_wait_stats ORDER BY wait_type ASC <br />GO <br />
まずは、現状の SQL Database で使用されることの多い、Business エディションで実行してみたいと思います。
SQL Database ではデータを 3 重化していますので、そのための ACK の応答 (SE_REPL_COMMIT_ACK) と、今回は INSERT のクエリを実行していますので、ログの書き込みに伴う待ち (WRITELOG) が大半を占めています。
続いて Basic で実行してみます。
先ほどは 1:53 で終了していたのですが、9:19 かかっています。
特筆してみた方がよさそうな待ち事象としては、LOG_RATE_GOVERNOR でしょうか。
Business の場合は、SE_REPL_COMMIT_ACK / WRITELOG が高い値を示していましたが、Basic の場合は、これらに加えて、LOG_RATE_GOVERNOR が高い値を示しており、処理実行中のトータルとして、435 秒 (7分15秒) 待ちが発生したようです。
GOVERNOR ということから、ログ書き込みのトランザクションレートを調整するための調整機構が入っているのかもしれないですね。
データ冗長化のための待ちの前にこの調整による待ちが入っているようで、これらの待ちが影響して、7分程度の処理の差が出ているのかもしれません。
続いて、Standard S1 の実行結果がこちらになります。
こちらは、4:35 で終了しています。
Basic の場合と、待ちの発生傾向は同じになっていますが、LOG_RATE_GOVERNOR は 162 秒 (2 分 42秒) となっているため、Basic と比較して低い値となっています。
最後に、Standard S2 の実行結果になります。
こちらは、処理時間が、3:03 で LOG_RATE_GOVERNOR が 62 秒 程度となっています。
最終的な待ち事象の結果がこちらです。
データの挿入系の処理の場合は、DTU が異なることで、書き込み性能に差が出てくるようですね。
wait_type | Business | Basic | Standard S1 | Standard S2 | ||||
Count | Time (ms) | Count | Time (ms) | Count | Time (ms) | Count | Time (ms) | |
ASYNC_TRANSPORT_STREAM | 3 | 0 | 3 | 0 | 3 | 0 | 2 | 0 |
CMEMTHREAD | 9 | 0 | 36 | 4 | 4 | 0 | 0 | 0 |
LOG_RATE_GOVERNOR | 0 | 0 | 8,956 | 435,217 | 5,407 | 162,228 | 2,831 | 62,191 |
PAGEIOLATCH_EX< /span> | 2 | 10 | 1 | 1 | 2 | 1 | 0 | 0 |
PAGEIOLATCH_SH | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
PAGEIOLATCH_UP | 1 | 0 | 1 | 0 | 1 | 0 | 1 | 0 |
PAGELATCH_EX | 2 | 0 | 2 | 0 | 1 | 0 | 3 | 0 |
RESOURCE_GOVERNOR_IDLE | 0 | 0 | 0 | 0 | 1 | 7 | 0 | 0 |
SE_REPL_COMMIT_ACK | 5,000 | 12,932 | 5,000 | 14,726 | 5,000 | 13,676 | 5,000 | 12,977 |
SE_REPL_QUEUE_TRUNCATE | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 0 |
SE_REPL_QUEUE_XACT_ACK | 0 | 0 | 6 | 1 | 0 | 0 | 0 | 0 |
SOS_SCHEDULER_YIELD | 37 | 0 | 1 | 0 | 15 | 14 | 24 | 0 |
WRITE_COMPLETION | 4 | 2 | 4 | 3 | 4 | 4 | 4 | 3 |
WRITELOG | 5,002 | 6,933 | 5,002 | 9,655 | 5,002 | 8,021 | 5,002 | 7,724 |
ポータルから各種メトリックを取得したものが以下になります。
Standard S1 の情報が個人的に納得いっていないですが…。
取得できるメトリックも既存のものと新しいものでは異なっており、新しいエディションのものは取得できる情報が増えています。
最後にSQL Query Stress を使って、以下のクエリを実行してみたいと思います。
<br />SELECT COUNT(*) FROM Table_1 WITH (NOLOCK) <br />ORDER BY NEWID() <br />
左上からBusiness / Basic / Standard S1 / Standard S2 となります。
データの件数はすべて同じなのですが、処理時間やエラーの発生状況が異なっています。
Basic で発生したエラーは以下になります。
Resource ID : 2. The session limit for the database is 150 and has been reached. See ‘http://go.microsoft.com/fwlink/?LinkId=267637’ for assistance.
Login failed for user ‘xxxx’.
This session has been assigned a tracing ID of ‘XXXXXXXXXXXXXXXXXXX’. Provide this tracing ID to customer support when you need assistance.
既存の Web / Business エディションの終了予定日もすでにアナウンスされていますので、新しいエディションを使用する際には、性能特性を意識しておいた方がよいのかもしれないですね。
2014/5/5 追記
Premium エディションでも測定してみました。
P1 / P2 の順になります。
# 無償分の枠がなくなって P3 は試せませんでした。
P1/P2 ともに 1:57 で処理が終了しました。
P1 の実行結果を見ると [LOG_RATE_GOVERNOR] の発生が少なくなっており、P2 では発生していません。
今回のクエリの INSERT 負荷では P1
/ P2 ともに調整が行われても同程度の性能となるようですね。
wait_type | Premium P1 | Premium P2 | ||
Count | Time (ms) | Count | Time (ms) | |
ASYNC_TRANSPORT_STREAM | 0 | 0 | 0 | 0 |
CMEMTHREAD | 0 | 0 | 0 | 0 |
LOG_RATE_GOVERNOR | 33 | 497 | ||
PAGEIOLATCH_EX | 1 | 0 | 1 | 0 |
PAGEIOLATCH_SH | 0 | 0 | 0 | 0 |
PAGEIOLATCH_UP | 1 | 0 | 1 | 0 |
PAGELATCH_EX | 3 | 0 | 2 | 0 |
RESOURCE_GOVERNOR_IDLE | 0 | 0 | 0 | 0 |
SE_REPL_COMMIT_ACK | 5,000 | 13,411 | 5,000 | 12,853 |
SE_REPL_QUEUE_TRUNCATE | 0 | 0 | 0 | 0 |
SE_REPL_QUEUE_XACT_ACK | 2 | 0 | 0 | 0 |
SOS_SCHEDULER_YIELD | 34 | 0 | 28 | 0 |
WRITE_COMPLETION | 4 | 3 | 4 | 2 |
WRITELOG | 5,002 | 7,354 | 5,002 | 7,346 |
wait_type | Business | Basic | Standard S1 | Standard S2 | Premium P1 | Premium P2 | ||||||
Count | Time (ms) | Count | Time (ms) | Count | Time (ms) | Count | Time (ms) | Count | Time (ms) | Count | Time (ms) | |
ASYNC_TRANSPORT_STREAM | 3 | 0 | 3 | 0 | 3 | 0 | 2 | 0 | 0 | 0 | 0 | 0 |
CMEMTHREAD | 9< /td> | 0 | 36 | 4 | 4 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
LOG_RATE_GOVERNOR | 0 | 0 | 8,956 | 435,217 | 5,407 | 162,228 | 2,831 | 62,191 | 33 | 497 | ||
PAGEIOLATCH_EX | 2 | 10 | 1 | 1 | 2 | 1 | 0 | 0 | 1 | 0 | 1 | 0 |
PAGEIOLATCH_SH | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
PAGEIOLATCH_UP | 1 | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 | 0 |
PAGELATCH_EX | 2 | 0 | 2 | 0 | 1 | 0 | 3 | 0 | 3 | 0 | 2 | 0 |
RESOURCE_GOVERNOR_IDLE | 0 | 0 | 0 | 0 | 1 | 7 | 0 | 0 | 0 | 0 | 0 | 0 |
SE_REPL_COMMIT_ACK | 5,000 | 12,932 | 5,000 | 14,726 | 5,000 | 13,676 | 5,000 | 12,977 | 5,000 | 13,411 | 5,000 | 12,853 |
SE_REPL_QUEUE_TRUNCATE | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
SE_REPL_QUEUE_XACT_ACK | 0 | 0 | 6 | 1 | 0 | 0 | 0 | 0 | 2 | 0 | 0 | 0 |
SOS_SCHEDULER_YIELD | 37 | 0 | 1 | 0 | 15 | 14 | 24 | 0 | 34 | 0 | 28 | 0 |
WRITE_COMPLETION | 4 | 2 | 4 | 3 | 4 | 4 | 4 | 3 | 4 | 3 | 4 | 2 |
WRITELOG | 5,002 | 6,933 | 5,002 | 9,655 | 5,002 | 8,021 | 5,002 | 7,724 | 5,002 | 7,354 | 5,002 | 7,346 |
検索については 1 秒程度の差となっていました。
どちらの場合も Standard と比較して性能は出ていますね。