Сравнение новых уровней SQL Azure с старыми

Ответ 1

Мы только что закончили сравнение производительности.

Я не могу публиковать наши SQL-запросы, но мы использовали 3 разных тестовых примера, которые соответствуют нашей обычной деятельности. В каждом тестовом случае мы выполнили несколько запросов с объединением таблиц и совокупными вычислениями (SUM, AVG и т.д.) Для нескольких тысяч строк. Наша тестовая база данных скромна - около 5 ГБ в размере нескольких миллионов строк.

Несколько замечаний: для каждого мы протестировали мою локальную машину, которая представляет собой 5-летний iMac, работающий под управлением Windows/SQL Server на виртуальной машине ( "Локальный" ), SQL Azure Business ( "Бизнес" ), SQL Azure Premium P1, SQL Azure Standard S2 и SQL Azure Standard S1. Основной уровень казался настолько медленным, что мы его не тестировали. Все эти тесты проводились без какой-либо другой активности в системе. Запросы не возвратили данные, поэтому производительность сети, надеюсь, не является фактором.

Вот наши результаты:

Test One

Local: 1 second
Business: 2 seconds
P1: 2 seconds
S2: 4 seconds
S1: 14 seconds

Test Two

Local: 2 seconds
Business: 5 seconds
P1: 5 seconds
S2: 10 seconds
S1: 30 seconds

Тест три

Local: 5 seconds
Business: 12 seconds
P1: 13 seconds
S2: 25 seconds
S1: 77 seconds

Выводы:

После нескольких дней работы с разными уровнями наша команда заключила несколько вещей:

• P1, похоже, работает на том же уровне, что и SQL Azure Business. (P1 - 10x цена).
• Основные и S1 слишком медленны для чего-либо, кроме базы данных стартеров.
• Бизнес-уровень - это общий сервис, поэтому производительность зависит от того, что другие пользователи на вашем сервере. Наша база данных показывает максимум 4.01% CPU, 0.77% Data IO, 0.14% Log IO, и мы испытываем серьезные проблемы с производительностью и тайм-ауты. Служба поддержки Microsoft подтвердила, что мы "на самом деле занят сервером".
• Уровень обслуживания обеспечивает непоследовательное обслуживание серверов и регионов. В нашем случае мы перешли на другой сервер в другом регионе, и наш сервис вернулся к норме. (мы рассматриваем это как временное решение)
• Уровни S1, S2, P1, похоже, обеспечивают одинаковые показатели по регионам. Мы протестировали Западный и Северо-Центральный.
• Учитывая вышеизложенные результаты, мы, как правило, обеспокоены будущим SQL Azure. Деловой уровень был отличным для нас в течение нескольких лет, но он должен выйти из строя через 12 месяцев. Новые уровни выглядят по сравнению с уровнем бизнеса.

Я уверен, что есть 100 способов, которые могут быть более научными, но я надеюсь, что эти статистические данные помогут другим подготовиться к оценке.

UPDATE:

Служба поддержки Microsoft предоставила нам очень полезный запрос для оценки использования вашей базы данных.

SELECT
       avg(avg_cpu_percent) AS 'Average CPU Percentage Used',
       max(avg_cpu_percent) AS 'Maximum CPU Percentage Used',
       avg(avg_physical_data_read_percent) AS 'Average Physical IOPS Percentage',
       max(avg_physical_data_read_percent) AS 'Maximum Physical IOPS Percentage',
                   avg(avg_log_write_percent) AS 'Average Log Write Percentage',
       max(avg_log_write_percent) AS 'Maximum Log Write Percentage',
       --avg(avg_memory_percent) AS 'Average Memory Used Percentage',
       --max(avg_memory_percent) AS 'Maximum Memory Used Percentage',
       avg(active_worker_count) AS 'Average # of Workers',
       max(active_worker_count) AS 'Maximum # of Workers'
FROM sys.resource_stats
WHERE database_name = 'YOUR_DATABASE_NAME' AND
start_time > DATEADD(day, -7, GETDATE())

Наиболее полезной частью является то, что проценты представляют% экземпляра S2. Согласно Microsoft Support, если вы на 100%, вы используете 100% S2, 200% будут эквивалентны экземпляру P1.

Нам очень повезло с экземплярами P1 сейчас, хотя разница в цене была шокером.

Ответ 2

Я являюсь автором сообщений в блоге по проверке производительности базы данных Azure SQL Database, упомянутых выше.

Сравнение IOPS с DTU довольно сложно для базы данных Azure SQL, поэтому в моих тестах я сосредоточился на подсчетах строк и пропускной способности (в мегабайтах в секунду).

Я был бы осторожен в использовании ставок транзакций, цитируемых Microsoft. Их базовые базы данных довольно малы, например. для стандартного уровня, который имеет емкость 250 ГБ, их базовые базы данных для S1 и S2 составляют всего 2 ГБ и 7 ГБ соответственно. При таких размерах я предлагаю, что SQL Server кэширует большую/большую часть базы данных, и поэтому их ориентир избегает худшего из прочитанного дросселирования, которое может повлиять на базы данных реального мира.

Я добавил новое сообщение о том, что новые уровни обслуживания достигают общей доступности и делают некоторые оценки изменений в производительности вокруг S0 и S1 в GA.

http://cbailiss.wordpress.com/2014/09/16/performance-in-new-azure-sql-database-performance-tiers/

Ответ 3

На самом деле нет никакого сопоставления между старыми и новыми предложениями, насколько я могу судить. Старые предложения - единственное, что действительно отличалось между предложением "Интернет" и "бизнес" - это размер, на который была ограничена база данных.

Однако на новых предложениях каждый уровень имеет связанные с ними показатели производительности. Поэтому, чтобы решить, какое предложение вам нужно переместить существующие базы данных, вам нужно выяснить, какой тип производительности требуется вашему приложению.

Ответ 4

По размеру Web и Business появляются значения между Basic и S1. Здесь сравнивается ссылка с диаграммой с новым и старым уровнями. Кажется, что маленькое яблоко хорошо апельсина, поэтому нет прямого картирования. Здесь также ссылка, специально адресованная людям, находящимся в настоящее время в Интернете и бизнес-уровнях.

Сравнение уровней

Часто задаваемые вопросы о заказе Web и Business Edition