Negli ultimi tempi mi è capitato spesso di confrontarmi con partner e clienti che “lamentavano” la lentezza delle loro applicazioni Web portate su Windows Azure e dovute a Windows Azure SQL Database (che per brevità chiamerò da ora in poi SQL Database).
Prima di tutto vediamo uno schema e alcuni principi fondamentali che ci aiutano a capire come ne funziona l’architettura e la comunicazione con un Web Role, un Worker o un Web Site.
| SQL Database è un database “gestito” da Windows Azure, basato su SQL Server, e realizzato in modo tale che voi non dobbiate preoccuparvi di installare e gestire il server SQL, ma che dobbiate solo pensare a realizzare la miglior struttura dati per la vostra applicazione. Per garantire questa “promessa” e il livello di servizio al 99.9%, SQL Database è replicato in tre Fault Domain del datacenter e ne viene eseguito il backup ogni 5 minuti per 14 giorni. Inoltre, quando eseguite una query verso SQL Database, un Load Balancer dirige la vostra query su una delle “copie” disponibili del Database, di fatto distribuendo il traffico delle vostre letture. In caso di scrittura, una scrittura viene considerata “completa” solo nel caso in cui la scrittura su tutte e tre le repliche sia andata a buon fine. Inoltre, quando usate SQL Database, siete in un ambiente condiviso con altri utenti e applicazioni, quindi l’efficienza delle vostre query avrà impatti positivi sia sulle vostre performance che su quelle degli altri che stanno usando la vostra stessa infrastruttura. Questi meccanismi, ovviamente, introducono delle “latenze” nella comunicazione tra il vostro applicativo e i dati, che sono “trascurabili” se avete indicizzato e ottimizzato il vostro DB in maniera efficiente e se eseguite poche chiamate in “serie” prima di far vedere una pagina, mentre hanno un impatto determinante sulle prestazioni della vostra applicazione in caso contrario. |  |
Ottimizzare le performance di un applicativo che usa SQL Database
Ci sono diverse tecniche in SQL Server per ottimizzare le performance delle vostre query, che si possono usare anche in SQL Database; inoltre i paradigmi di programmazione come quelli di Asp.net MVC, che tendono a farvi eseguire le query verso il database in “parallelo”, aiutano ad ottenere performance migliori, rispetto all’esecuzione di molte query in serie prima di mostrare una pagina web all’utente finale (anche 10 o 15 sono un numero che ha degli impatti).
In SQL Database non si possono usare il profiler e l’index tuning wizard per scoprire dove sono i vostri “colli di bottiglia”, ma si possono utilizzare le Dynamic Management Views, delle viste di sistema di SQL Server che vi indicano quali sono le performance delle vostre query e quali sono gli indici che potreste introdurre per migliorarle.
Inoltre, è anche importante considerare come gestite la connessione al vostro DB per essere più efficienti.
Trattare nel dettaglio questi argomenti in questa sede potrebbe rendere questo articolo lungo e mi farebbe correre il rischio di essere superficiale, perciò vi rimando a una serie di articoli tecnici che potete sfruttare come punto di partenza:
- Performance delle Query:
- Improving Your I/O Performance: http://blogs.msdn.com/b/sqlazure/archive/2010/07/27/10043069.aspx
- Gaining Performance Insight into SQL Database: http://social.technet.microsoft.com/wiki/contents/articles/1657.gaining-performance-insight-into-windows-azure-sql-database.aspx
- Uncover Hidden Data to Optimize Application Performance: http://msdn.microsoft.com/en-us/magazine/cc135978.aspx
- http://social.technet.microsoft.com/wiki/contents/articles/1104.troubleshoot-and-optimize-queries-with-windows-azure-sql-database-en-us.aspx
- Connettività a SQL Database:
- SQL Database Connection Management: http://social.technet.microsoft.com/wiki/contents/articles/1541.windows-azure-sql-database-connection-management-en-us.aspx
- Retry Logic: http://social.technet.microsoft.com/wiki/contents/articles/4235.retry-logic-for-transient-failures-in-windows-azure-sql-database-en-us.aspx
- Connectivity Troubleshooting: http://social.technet.microsoft.com/wiki/contents/articles/1719.windows-azure-sql-database-connectivity-troubleshooting-guide.aspx
Altre due risorse interessanti per integrare gli articoli citati sono:
- la sezione che riguarda SQL Database nella guida Best Practices for the Design of Large-Scale Services: http://msdn.microsoft.com/en-us/library/windowsazure/jj717232.aspx
- la guida scaricabile SQL Azure Performance and Elasticity Guide: http://www.microsoft.com/en-us/download/details.aspx?id=26664
Se cercate consigli in Italiano per migliorare le performance su SQL Server e per conoscerlo più a fondo, vi consiglio il blog del mio collega Andrea Benedetti su Technet.
SQL Database e SQL Server su una Virtual Machine
Ci sono comunque casi in cui l’opzione di poter installare SQL Server in una Virtual Machine di Windows Azure si rende preferibile all’utilizzo e all’adozione immediata di SQL Database, tra cui provo a citare i principali esempi:
- il limite fisico dei 150 GB per database di SQL Database
- l’utilizzo del CLR nelle stored procedure
- l’utilizzo del full-text search
- un problema di regolamentazione per cui i dati del vostro applicativo non possono risiedere in un ambiente condiviso (seppur isolato a livello di sicurezza)
- la necessità di usare il Transparent Data Encryption
- la forte dipendenza da un application design o da una politica di partizionamento dei dati che non può essere rapidamente modificata
- …la necessità di usare Analysis o Integration Services
![Smile]()
Vi ricordo che con la prova gratuita di Windows Azure di 90 giorni avete a disposizione 1 GB di SQL Database e una macchina virtuale small per provare SQL Server su una VM, per scegliere quello che fa più al caso vostro 
- Vito