new - Comparando los nuevos niveles de SQL Azure con los antiguos
portal azure web (4)
Ahora que Microsoft hizo que los nuevos niveles de servicio de SQL Azure estén disponibles (Básico, Estándar, Premium) estamos tratando de descubrir cómo se correlacionan con los existentes (Web y Negocio).
Básicamente, hay seis niveles de rendimiento en el nuevo desglose de niveles: Básico, S1, S2, P1, P2 y P3 (detalles aquí: http://msdn.microsoft.com/library/dn741336.aspx )
¿Alguien sabe cómo los antiguos niveles de la base de datos se asignan a esos seis niveles? Por ejemplo, ¿Business Equivalente de un S1? S2?
Necesitamos poder responder a esta pregunta para determinar a qué niveles / niveles de servicio migrar nuestras bases de datos existentes.
En realidad, no hay ningún tipo de mapeo entre las ofertas antiguas y las nuevas, como puedo ver. Las ofertas anteriores, lo único que era realmente diferente entre la oferta "web" y "comercial" era el tamaño al que se limitaba la base de datos.
Sin embargo, en las nuevas ofertas, cada nivel tiene métricas de rendimiento asociadas. Entonces, para decidir qué oferta necesita mover sus bases de datos existentes, necesita averiguar qué tipo de rendimiento necesita su aplicación.
Parece en términos de tamaño Web y Business caen entre Basic y S1. Aquí hay un enlace que tiene un gráfico con los niveles nuevos y antiguos comparados. Parece una pequeña manzana a las naranjas honestamente así que no hay un mapeo directo. Aquí también hay un enlace dirigido específicamente a las personas que se encuentran actualmente en la Web y los Niveles de negocios.
Soy el autor de las publicaciones del blog Azure SQL Database Performance Testing mencionadas anteriormente.
Hacer comparaciones de IOPS a DTU es bastante difícil para Azure SQL Database, por lo que me concentré en los recuentos de filas y tasas de rendimiento (en MB por segundo) en mis pruebas.
Sería prudente sobre el uso de las tasas de transacción citadas por Microsoft, sus bases de datos de referencia son bastante pequeñas, por ejemplo, para el nivel estándar, que tiene una capacidad de 250 GB, sus bases de datos de referencia para S1 y S2 son solo de 2 GB y 7 GB respectivamente. En estos tamaños, sugiero que SQL Server está almacenando en caché gran parte de la base de datos y, como tal, su punto de referencia es evitar lo peor de la aceleración de lectura que probablemente afecte a las bases de datos del mundo real.
He agregado una nueva publicación sobre los nuevos niveles de servicio que afectan a la disponibilidad general y hago algunas estimaciones de los cambios en el rendimiento en S0 y S1 en GA.
http://cbailiss.wordpress.com/2014/09/16/performance-in-new-azure-sql-database-performance-tiers/
Acabamos de terminar una comparación de rendimiento.
No puedo publicar nuestras consultas SQL, pero utilizamos 3 casos de prueba diferentes que coinciden con nuestra actividad normal. En cada caso de prueba, realizamos varias consultas con combinaciones de tablas y cálculos agregados (SUM, AVG, etc.) para algunos miles de filas. Nuestra base de datos de pruebas es modesta, de aproximadamente 5 GB de tamaño y unos pocos millones de filas.
Algunas notas: para cada una, probamos mi máquina local, que es un iMac de 5 años que ejecuta Windows / SQL Server en una máquina virtual ("Local"), SQL Azure Business ("Business"), SQL Azure Premium P1, SQL Azure Standard S2 y SQL Azure Standard S1. El nivel básico parecía tan lento que no lo probamos. Todas estas pruebas se realizaron sin otra actividad en el sistema. Las consultas no arrojaron datos, por lo que el rendimiento de la red no fue un factor.
Aquí estaban nuestros resultados:
Prueba uno
Local: 1 second
Business: 2 seconds
P1: 2 seconds
S2: 4 seconds
S1: 14 seconds
Prueba dos
Local: 2 seconds
Business: 5 seconds
P1: 5 seconds
S2: 10 seconds
S1: 30 seconds
Prueba tres
Local: 5 seconds
Business: 12 seconds
P1: 13 seconds
S2: 25 seconds
S1: 77 seconds
Conclusiones
Después de trabajar con los diferentes niveles durante unos días, nuestro equipo concluyó algunas cosas:
- P1 parece funcionar al mismo nivel que SQL Azure Business. (P1 es 10 veces el precio)
- Basic y S1 son demasiado lentos para cualquier cosa que no sea una base de datos inicial.
- Business tier es un servicio compartido, por lo que el rendimiento depende de lo que otros usuarios tengan en su servidor. Nuestra base de datos muestra un máximo de 4.01% de CPU, 0.77% de datos de E / S, 0.14% de registro de E / S y estamos experimentando problemas de rendimiento y tiempos de espera. El soporte técnico de Microsoft confirmó que estamos "simplemente en un servidor realmente ocupado".
- Business tier ofrece un servicio incoherente en servidores y regiones. En nuestro caso, nos mudamos a un servidor diferente en una región diferente y nuestro servicio volvió a la normalidad. (vemos eso como una solución temporal)
- Los niveles S1, S2, P1 parecen proporcionar el mismo rendimiento en todas las regiones. Probamos West y North Central.
- Teniendo en cuenta los resultados anteriores, generalmente nos preocupa el futuro de SQL Azure. El nivel de negocios ha sido excelente para nosotros durante algunos años, pero está programado para que esté fuera de servicio en 12 meses. Los nuevos niveles parecen demasiado caros en comparación con el nivel Business.
Estoy seguro de que hay 100 formas en que esto podría ser más científico, pero espero que esas estadísticas ayuden a otros a prepararse para evaluar.
ACTUALIZAR:
El soporte de Microsoft nos envió una consulta muy útil para evaluar el uso de su base de datos.
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())
La parte más útil es que los porcentajes representan% de una instancia de S2. De acuerdo con el soporte de Microsoft, si está al 100%, está usando el 100% de un S2, el 200% sería equivalente a una instancia de P1.
Estamos teniendo muy buena suerte con las instancias de P1 ahora, aunque la diferencia de precio ha sido impactante.