对于这种情况，为什么SQL Azure数据库性能在Web和新的高级版上差别如此之大

Question

We are migrating an website to SQL Azure and found a scenario where there is a very significant performance difference between our current hosting and azure database.

To be clear, the stored procedure code is written poorly and can be fixed but what I would like to understand is the reasons behind the performance difference.

Here is the offending code inside the procedure that is causing the problem

declare @curPinNumber int
set @curPinNumber = 183843692

declare @pinNumber int
set @pinNumber = 0
while @pinNumber < 10000
begin
    set @curPinNumber = @curPinNumber + 1
    insert into PinNumbers(pinNumber, pinNumberText, whenLastUsed, siteID) 
    values(@curPinNumber, right('0000' + cast(@pinNumber as varchar), 4), '1970-01-01', 999)
    set @pinNumber = @pinNumber + 1     
end

Here are the test results for the procedure

azure sql database web edition

• run #1: 41 seconds
• run #2: 37 seconds
• run #3: 37 seconds

standard edition s1 (15 DTU's - MS have since made S1 20 DTU's)

• run #1: 3 minutes, 44 seconds
• run #2: 3 minutes, 41 seconds
• run #3: 3 minutes, 42 seconds

standard edition s2 50 DTU's (not a mistake - all were very consistent)

• run #1: 1 minute, 51 seconds
• run #2: 1 minute, 51 seconds
• run #3: 1 minute, 51 seconds

premium edition P1 (100 DTU's)

• run #1: 56 seconds
• run #2: 55 seconds
• run #3: 55 seconds

premium edition P2 (200 DTU's)

• run #1: 33 seconds
• run #2: 33 seconds
• run #3: 34 seconds

*The two vm's below have seperate log and data disks.

sql on a virtual machine (basic, 1 core, 1.75gb ram. sql enterprise core edn)

• run #1: 53 seconds
• run #2: 50 seconds
• run #3: 51 seconds

sql on a virtual machine (basic, 2 core, 3.5gb ram. sql enterprise core edn)

• run #1: 49 seconds
• run #2: 50 seconds
• run #3: 51 seconds

my desktop pc

• run #1: 3.7 seconds
• run #2: 3.1 seconds
• run #3: 3.1 seconds

current hosting (which has 7 year old equipment)

• run #1: 6.1 seconds
• run #2: 6.0 seconds
• run #3: 6.0 seconds

So my assumption here was a key factor is the logging and log flushes that are taking place, possibly the write ahead transaction logging http://msdn.microsoft.com/en-us/library/ms186259.aspx

Adding a BEGIN / COMMIT TRAN block or joining from an existing preset table with 10,000 rows indeed gets the performance back to 1-2 seconds on the web edition of sql azure, and even faster on my local machine.

I would have expected Azure to be in a similar performance zone to my desktop or old hosting

My question is why on Azure is the difference so magnified? I'm trying to judge if this just a corner case that we happened to pick up during testing and most importantly what things we should look out for in our migration.

Answer 1

This is most likely because of communication between the machine where you issue the batch from and the database service. Try and issue SET NOCOUNT ON first in the batch to turn off sending rows affected notifications back to the client.