VENTES: 1-800-867-1389

Éléments à prendre en considération pour les performances de la Base de données SQL de Windows Azure

Mis à jour: janvier 2014

Cet article traite des meilleures pratiques permettant d'améliorer les performances des applications qui utilisent une base de données migrée vers Base de données SQL Windows Azure. Lorsqu'un serveur de base de données partage le même rack que le serveur d'applications, les meilleures pratiques suivantes peuvent avoir un impact réduit. Toutefois, lorsque le serveur de base de données est déplacé vers un centre de données distant, ces mêmes meilleures pratiques sont critiques pour conserver de bonnes performances. En outre, Windows Azure est un environnement partagé car toutes les ressources sont partagées avec d'autres applications, rôles et bases de données. Grâce à l'équilibrage de la charge réseau et aux composants de passerelle, Windows Azure assure des économies d'échelle et fournit les ressources de calcul et réseau plus efficacement à l'ensemble de l'environnement. Prenez en considération ces facteurs lors de la conception et du déploiement d'applications sur Windows Azure.

Cet article traite des meilleures pratiques de conception et d'implémentation permettant d'optimiser les performances de l'environnement Base de données SQL Windows Azure. En particulier, il aborde celles qui permettent de surmonter deux difficultés pouvant entraîner des problèmes de performances lorsque les bases de données sur site sont migrées vers Base de données SQL Windows Azure :

Un certain nombre d'autres articles afférents aux performances de la base de données Windows Azure sont répertoriés ci-dessous :

La Base de données SQL Windows Azure permet de réserver des ressources pour votre base de données via l'édition Premium actuellement disponible via le programme d'évaluation. Le document Aperçu Premium du Guide de Base de données SQL fournit des instructions pour vous aider à déterminer si la base de données Premium disponible via le programme d'évaluation est adaptée pour votre application, ainsi que des recommandations pour paramétrer votre application de façon à tirer le meilleur parti de cette fonctionnalité.

L'article Base de données SQL Windows Azure et SQL Server -- Comparaison des performances et de l'évolutivité décrit un certain nombre de modèles de performances pour la Base de données SQL, plusieurs techniques permettant d'évaluer correctement les performances et plusieurs scripts SQL qui vous aident à évaluer et dépanner vos instances de la Base de données SQL Server.

  • Gestion des connexions

  • Latence du réseau entre la couche applicative et la couche Base de données

Auteurs : Silvano Coriani, Steve Howard
Analyseurs : Mark Simms, Valery Mizonov, Kun Cheng, Paolo Salvatori, Jaime Alva Bravo

Gestion des connexions dans Base de données SQL Windows Azure

Les connexions de bases de données peuvent s'interrompre plus souvent lorsqu'une base de données est hébergée dans Base de données SQL Windows Azure plutôt que dans un environnement sur site. Les utilisateurs peuvent interpréter ces arrêts comme des problème de performances si les applications ne détectent pas rapidement la perte de connexion et si elles ne se reconnectent pas en cas d'erreur temporaire ou transitoire. En tant que fournisseur de service de base de données à grande échelle et multi-locataires sur des ressources partagées, Base de données SQL Windows Azure regroupe chaque base de données sur trois nœuds et équilibre les ressources entre les nœuds de cluster pour fournir une bonne expérience à tous les locataires. Un exemple d'erreur transitoire est la détection d'une utilisation importante d'un serveur qui héberge plusieurs bases de données par Base de données SQL Windows Azure. Dans ce cas, Base de données SQL Windows Azure peut basculer l'une des bases de données sur un nœud de cluster secondaire dont la charge de traitement est inférieure. Le basculement met fin à toutes les connexions ouvertes sur la base de données et restaure les transactions en cours. Les applications doivent rapidement détecter l'erreur, se reconnecter à la base de données et retenter leur dernière transaction.

La liste suivante répertorie une partie des raisons pour lesquelles Base de données SQL Windows Azure peut arrêter les connexions :

  • La topologie de réseau générale de Base de données SQL Windows Azure implique des pare-feu, des programmes d'équilibrage de charge et des passerelles TDS (Tabular Data Stream). Chacun des composants de la topologie ajoute une couche entre le code d'accès aux données et le nœud de base de données. Les erreurs dans ces couches supplémentaires peuvent arrêter les connexions.

  • Base de données SQL Windows Azure rassemble et analyse en continu les statistiques d'utilisation de la base de données. En fonction de ces statistiques, Base de données SQL Windows Azure peut mettre fin à la connexion si nécessaire pour conserver le service dans un état sain.

  • Les attaques par déni de service aboutissent au blocage des connexions par Base de données SQL Windows Azure à partir d'une adresse IP spécifique, pendant un certain temps.

  • Certains événements de basculement peuvent aboutir à l'arrêt soudain d'une session par Base de données SQL Windows Azure. (Notez qu'aucune connexion ouverte sur un nœud avant un événement de basculement ne sera disponible sur le nouveau nœud après le basculement.)

La liste précédente répertorie uniquement certaines des raisons d'arrêt de connexion. Pour plus d'informations sur les erreurs de connexion et pour obtenir des informations sur la façon de gérer des connexions dans Base de données SQL Windows Azure, consultez les documents suivants :

Options pour gérer la gestion des connexions dans le code

Pour gérer les problèmes de connexion de Base de données SQL Windows Azure, Microsoft a travaillé au développement des fonctionnalités suivantes :

  • Une approche cohérente sur la façon de spécifier des informations de base, telles que les noms de serveur et les informations d'identification de sécurité, ou une fidélité totale à l'aide d'outils comme le programme de copie en bloc (bpc.exe). Par exemple, à partir de SQL Server Native Client 11, version 4.0 JDBC et du fournisseur de données .NET Framework pour SQL Server (System.Data.SqlClient) de .NET Framework 4.0, vous n'avez pas besoin de spécifier nom d'utilisateur@serveur lors de l'accès à Base de données SQL Windows Azure.

  • La garantie que toutes les technologies de connexion peuvent contenir une connexion, même pendant des périodes inactives. Par exemple, contrairement à Windows, la plateforme Java ne gère pas en mode natif les intervalles « Keep Alive » pour les connexions de base de données. Par conséquent, les composants JDBC qui se connectent à Base de données SQL Windows Azure nécessitent que vous apportiez des modifications au paramètre du Registre pour garantir que les connexions inactives ne soient pas supprimées.
    Pour plus d'informations, consultez la rubrique de la bibliothèqye MSDN Connexion à une base de données sur la Base de données SQL dans Windows Azure.

En outre, Microsoft a déployé en permanence plusieurs mises à jour de la plupart des bibliothèques d'accès aux données et des versions des services Base de données SQL Windows Azure. La plus significative d'entre elles est peut-être celle qui concerne le Bloc d'applications de gestion d'erreurs transitoires, une bibliothèque d'applications qui fournit une logique de gestion d'erreurs transitoires. (Les erreurs transitoires sont des erreurs qui se produisent en raison d'une condition temporaire, comme des problèmes de connectivité réseau ou d'indisponibilité de service.) La section suivante fournit des informations plus détaillées sur la façon d'utiliser le bloc d'applications de gestion d'erreurs transitoires sur une application.

Description rapide de la procédure d'utilisation du bloc d'applications de gestion d'erreurs transitoires

Le bloc d'applications de gestion d'erreurs transitoires encapsule des informations sur les erreurs transitoires qui peuvent se produire lorsque vous utilisez les services Windows Azure suivants dans votre application :

  • Base de données SQL Windows Azure

  • Bus de service Windows Azure

  • Stockage dans Windows Azure

  • Service caching de Windows Azure

Chacun de ces services peut connaître des erreurs transitoires. Par conséquent, le bloc d'applications de gestion d'erreurs transitoires utilise des stratégies de détection des erreurs spécifiques à chaque service. De même, chaque application nécessite des stratégies de gestion d'erreur distinctes. Pour s'adapter à ces différences, le bloc d'applications de gestion d'erreurs transitoires fournit différentes méthodes de logique de nouvelle tentative, qui traitent les différents scénarios d'erreurs transitoires. Ces stratégies prédéfinies peuvent être étendues en créant des classes personnalisées qui exposent des interfaces bien définies.

L'utilisation du bloc d'applications de gestion d'erreurs transitoires dans les applications existantes n'a qu'un impact très faible. En fonction de sa conception, le bloc d'applications de gestion d'erreurs transitoires offre plusieurs classes et méthodes d'extension qui simulent le comportement d'une couche d'accès aux données ADO.NET classique.

Pour illustrer la facilité d'utilisation de cette bibliothèque d'applications, les paragraphes qui suivent expliquent comment appliquer le bloc d'applications de gestion d'erreurs transitoires à un code existant. L'exemple suivant illustre une méthode simple qui interroge une base de données et consomme le jeu de résultats :

        public static void ReadFromDB()
        {

            using (SqlConnection conn = new SqlConnection(connString))
            {
                try
                {
                    conn.Open();

                    SqlCommand selectCommand = 
new SqlCommand(@"SELECT SOH.SalesOrderID
                         FROM SalesLT.SalesOrderHeader SOH 
                         JOIN SalesLT.SalesOrderDetail SOD ON SOH.SalesOrderID = SOD.SalesOrderID
                         JOIN SalesLT.Product P ON SOD.ProductID = P.ProductID
                         JOIN SalesLT.Customer C ON SOH.CustomerID = C.CustomerID
                         JOIN SalesLT.CustomerAddress CA on C.CustomerID = CA.CustomerID
                         JOIN SalesLT.Address A on CA.AddressID = A.AddressID
                         WHERE A.City=@City", conn);

                    selectCommand.Parameters.Add(new SqlParameter("@City", SqlDbType.VarChar, 20, ParameterDirection.Input, false, 0, 0, "", DataRowVersion.Current, "London"));
                    selectCommand.CommandType = CommandType.Text;

                    IDataReader dataReader = selectCommand.ExecuteReader();

                    while (dataReader.Read())
                    {
                        Console.WriteLine("OrderID: {0}", dataReader["SalesOrderID"]);
                    }
                }
                catch (Exception e)
                {
                    Console.WriteLine("Exception: {0}",e.Message);
                }
            }

Pour rendre le code plus fiable, définissez d'abord une stratégie de nouvelle tentative pertinente. Une stratégie de nouvelle tentative incrémentielle est préférable. Pour implémenter cette stratégie, utilisez tout d'abord la classe Microsoft.Practices.EnterpriseLibrary.WindowsAzure.TransientFaultHandling.SqlAzure.SqlAzureTransientErrorDetectionStrategy. Cette classe désactive les codes d'erreur relatifs aux conditions d'erreurs transitoires. Ensuite, remplacez la classe System.Data.SqlClient SqlConnection par la classe Microsoft.Practices.EnterpriseLibrary.WindowsAzure.TransientFaultHandling.SqlAzure.ReliableSqlConnection, comme illustré dans l'exemple de code suivant :

        public static void ReadFromDBWithReliableConnection()
        {

            // Define retry Strategy and Policy
            var retryStrategy = new Incremental(5, TimeSpan.FromSeconds(1), TimeSpan.FromSeconds(2));
            var retryPolicy = new RetryPolicy<SqlAzureTransientErrorDetectionStrategy>(retryStrategy);

            // Receive notifications about retries.
            retryPolicy.Retrying += new EventHandler<RetryingEventArgs>(retryPolicy_Retrying);

            using (ReliableSqlConnection conn = new ReliableSqlConnection(connString,retryPolicy))
            {
                try
                {
                    conn.Open();

                    SqlCommand selectCommand = new SqlCommand(@"SELECT SOH.SalesOrderID
                                        FROM SalesLT.SalesOrderHeader SOH 
                                        JOIN SalesLT.SalesOrderDetail SOD ON SOH.SalesOrderID = SOD.SalesOrderID
                                        JOIN SalesLT.Product P ON SOD.ProductID = P.ProductID
                                        JOIN SalesLT.Customer C ON SOH.CustomerID = C.CustomerID
                                        JOIN SalesLT.CustomerAddress CA on C.CustomerID = CA.CustomerID
                                        JOIN SalesLT.Address A on CA.AddressID = A.AddressID
                                        WHERE A.City=@City");

                    selectCommand.Parameters.Add(new SqlParameter("@City", SqlDbType.VarChar, 20, ParameterDirection.Input, false, 0, 0, "", DataRowVersion.Current, "London"));
                    selectCommand.CommandType = CommandType.Text;

                    IDataReader dataReader = conn.ExecuteCommand<IDataReader>(selectCommand);

                    while (dataReader.Read())
                    {
                        Console.WriteLine("OrderID: {0}", dataReader["SalesOrderID"]);
                    }
                }
                catch (Exception e)
                {
                    Console.WriteLine("Exception: {0}", e.Message);
                }
            }
        
        }

L'exemple de code précédent, lorsque vous avez ajouté la logique de nouvelle tentative appropriée, a également remplacé le code SQLConnection existant par le code ReliableSQLConnection. Pour réduire la quantité de code à réécrire, il existe une approche alternative, qui utilise les méthodes d'extension fournies avec le bloc d'applications de gestion d'erreurs transitoires. Cette méthode réduit non seulement la quantité de réécriture nécessaire, mais offre également une approche générique pour ajouter des fonctions de nouvelle tentative à une application ADO.Net. Pour utiliser les méthodes d'extension, remplacez Open() et les différentes méthodes Execute (telles que ExecuteScalar(), ExecuteReader() ou ExecuteNonQuery()) par leurs équivalents de logique de nouvelle tentative, tels que OpenWithRetry() ou ExecuteScalarWithRetry(). Cela est illustré par l'exemple de code suivant :

        public static void ReadFromDBWithExecute()
        {

            // Define retry Strategy and Policy
            var retryStrategy = new Incremental(5, TimeSpan.FromSeconds(1), TimeSpan.FromSeconds(2));
            var retryPolicy = new RetryPolicy<SqlAzureTransientErrorDetectionStrategy>(retryStrategy);

            // Receive notifications about retries.
            retryPolicy.Retrying += new EventHandler<RetryingEventArgs>(retryPolicy_Retrying);

            try
            {
                retryPolicy.ExecuteAction(
                  () =>
                  {
                      using (SqlConnection conn = new SqlConnection(connString))
                      {
                          conn.OpenWithRetry();

                          SqlCommand selectCommand = new SqlCommand(@"SELECT SOH.SalesOrderID
                                                FROM SalesLT.SalesOrderHeader SOH 
                                                JOIN SalesLT.SalesOrderDetail SOD ON SOH.SalesOrderID = SOD.SalesOrderID
                                                JOIN SalesLT.Product P ON SOD.ProductID = P.ProductID
                                                JOIN SalesLT.Customer C ON SOH.CustomerID = C.CustomerID
                                                JOIN SalesLT.CustomerAddress CA on C.CustomerID = CA.CustomerID
                                                JOIN SalesLT.Address A on CA.AddressID = A.AddressID
                                                WHERE A.City=@City",conn);

                          selectCommand.Parameters.Add(new SqlParameter("@City", SqlDbType.VarChar, 20, ParameterDirection.Input, false, 0, 0, "", DataRowVersion.Current, "London"));
                          selectCommand.CommandType = CommandType.Text;

                          // Execute the above query using a retry-aware ExecuteCommand method which will
                          // automatically retry if the query has failed (or connection was dropped)
                          IDataReader dataReader = selectCommand.ExecuteReaderWithRetry(retryPolicy);
                          
                            while (dataReader.Read())
                            {
                                Console.WriteLine("OrderID: {0}", dataReader["SalesOrderID"]);
                            }                          
                      }
                  });
            }
            catch (Exception e)
            {
                Console.WriteLine("Exception: {0}", e.Message );
            }

        }

Le bloc d'applications de gestion d'erreurs transitoires prend en charge la déclaration de stratégies de nouvelle tentative configurables. Pour plus d'informations sur la déclaration de stratégies de nouvelle tentative, consultez Spécification de stratégies de nouvelle tentative dans la configuration

Les exemples de code présentés ici offrent un aperçu rapide de l'utilisation du bloc d'applications de gestion d'erreurs transitoires. Pour obtenir des informations plus détaillées sur l'utilisation de cette bibliothèque d'applications, consultez le didacticiel TechNet Wiki : Logique de nouvelle tentative pour les erreurs transitoires dans la Base de données SQL de Windows Azure

Latence du réseau dans Base de données SQL Windows Azure

Outre les erreurs de connexion, la latence du réseau est le problème de performances le plus fréquemment rencontré par les utilisateurs de Base de données SQL Windows Azure.

Tandis que l'impact de la latence Internet est bien connu, les utilisateurs tendent à sous-estimer l'impact de la latence entre l'application et Base de données SQL Windows Azure. Même si le même datacenter héberge l'application et les bases de données, la latence est généralement plus élevée que celle d'un environnement traditionnel sur site. Cette latence plus élevée est due à la nature multi-locataires de Windows Azure. En outre, cette latence plus élevée amplifie l'impact des comportements d'application « bavards », puisque chaque appel à la base de données connaît une latence supplémentaire qui peut dégrader davantage les performances globales. Par conséquent, les applications « bavardes » mettent beaucoup plus de temps à accéder à une base de données hébergée dans Base de données SQL Windows Azure par rapport à une base de données SQL Server hébergée sur site.

Outre la latence entre l'application et Base de données SQL Windows Azure, il existe une latence plus élevée dans les communications entre les différents composants distribués de votre solution. Ce type de latence est peut-être l'une des plus grandes différences entre les applications sur site et les applications dans le cloud. Elle se produit pour les communications entre l'utilisateur et l'application, et pour les communications entre l'application et Base de données SQL Windows Azure.

Du point de vue de l'utilisateur, ces causes de latence se traduisent par les temps de réponse perçus suivants :

Response Time = 2 x (Latency_1 + Latency_2) + Application_Processing_Time + Query_Exec_Time

  • Latency_1 est la latence entre l'utilisateur final et le centre de données qui héberge l'application. (Ce type de latence existe également dans les environnements sur site.)

  • Latency_2 est la latence entre l'application et les bases de données dans Base de données SQL Windows Azure.

Pour garantir des performances optimales, nous vous recommandons d'exécuter les actions de base suivantes en premier :

  • Réduisez Latency_1 en sélectionnant un centre de données le plus proche possible de la plupart de vos utilisateurs.

  • Réduisez Latency_2 en colocalisant les données avec l'application Windows Azure pour réduire les boucles réseau.

  • Réduisez Application_Processing_Time et Query_Exec_Time en suivant les meilleures pratiques générales appliquées aux bases de données sur site pour l'accès à la couche de données, pour la gestion des performances et pour le code d'optimisation.

Réduire la distance entre les données et les applications

Il est important de placer vos bases de données hébergées aussi près que possible de l'endroit où l'application s'exécute Si votre application s'exécute sur un centre de données situé en Amérique du Nord, le fait d'héberger la base de données dans ce centre de données donne la boucle la plus courte et, par conséquent, la latence liée à la distance la plus faible.

Bien qu'il soit possible d'accéder à une base de données hébergée dans Windows Azure à partir d'une application hébergée sur site, gardez à l'esprit que cela génère une latence plus élevée pour l'accès aux données et, également, des coûts de sortie des données à partir du centre de données.

Dans les cas où les données doivent être accédées à partir de plusieurs sites géographiques, servez-vous du réseau de distribution de contenu pour distribuer des données statiques à travers plusieurs sites. Ou bien, créez plusieurs copies d'une base de données dans chaque centre de données et utilisez Synchronisation des données SQL (Aperçu) pour synchroniser les données entre elles. Ces approches permettent d'améliorer les performances des applications qui s'exécutent sur plusieurs sites géographiques en plaçant les données plus près des différentes instances de l'application et en réduisant la latence totale.

noteRemarque
Synchronisation des données SQL (Aperçu) est actuellement disponible uniquement en version préliminaire, dans le but de fournir des commentaires pour les versions futures, mais ne doit pas être utilisé dans des environnements de production.

Réduire les boucles réseau

S'il est important de réduire les boucles réseau pour une application sur site, cela l'est d'autant plus avec Windows Azure. Les requêtes traitées par Base de données SQL Windows Azure doivent passer par les couches d'équilibrage de la charge réseau, ainsi que par la passerelle de protocole TDS, avant d'être reçues par Base de données SQL Windows Azure. Si cette abstraction permet à Base de données SQL Windows Azure de fournir une mise à l'échelle et la disponibilité à l'utilisateur final, elle requiert également un certain volume de traitement qui aboutit à une petite latence sur chaque boucle. Dans les applications qui envoient des données à Base de données SQL Windows Azure dans plusieurs boucles séquentielles, on peut constater un impact significatif sur les performances.

Pour réduire les effets des boucles, suivez les mêmes meilleures pratiques suivies pour les applications sur site :

  • Utilisez les procédures stockées, notamment, pour inclure une logique complexe d'accès aux données et des comportements transactionnels — Lorsque vous effectuez des appels consécutifs et le deuxième appel dépend des données retournées par le premier, si vous utilisez une procédure stockée pour créer la logique qui génère deuxième appel, vous éliminez une ou plusieurs boucles et vous accélérez les performances. Cette méthode réduit naturellement les boucles, ainsi que le verrouillage et l'utilisation des ressources côté serveur.

  • Réduisez l'utilisation des curseurs ou de l'accès ligne par ligne — Utilisez des opérations basées sur des ensembles lorsque cela est possible. Si vous devez utiliser des curseurs, utilisez un curseur côté client.

  • Utilisez les paramètres table pour envoyer plusieurs lignes à Base de données SQL Windows Azure dans chaque boucle — Base de données SQL Windows Azure utilise les paramètres table de la même façon que les versions sur site du moteur de base de données de SQL Server. L'utilisation des paramètres table réduit les appels multiples à la même procédure stockée pour traiter un ensemble d'enregistrements/valeurs. Vous pouvez également passer des paramètres tabulaires à une seule requête paramétrable, telle que SELECT, INSERT, UPDATE ou la commande DELETE.
    Pour plus d'informations, consultez la rubrique suivante dans la documentation en ligne Utiliser des paramètres table.

  • Utilisez la mise en cache locale lorsque cela est possible — La mise en cache locale peut vous permettre de réutiliser les mêmes résultats en réduisant les boucles vers Base de données SQL Windows Azure. En outre, gardez à l'esprit que vous pouvez mettre en cache des appels aux procédures stockées qui retournent la même valeur lorsque les données sont identiques.

  • Utilisez la mise en cache de Windows Azure lorsque cela est possible — Utilisez la mise en cache de Windows Azure pour les données de recherche en lecture seule afin de réduire le trafic réseau vers Base de données SQL Windows Azure. Pour plus d'informations, consultez Réduire les boucles réseau à l'aide de la mise en cache de Windows Azure.

  • Mettez en cache les métadonnées et les données lorsque cela est possible.

  • Évitez la récupération des métadonnées à l'exécution, si possible.

  • Évitez les classes comme SqlCommandBuilder — Ces classes interrogent des métadonnées au moment de l'exécution, entraînant des boucles supplémentaires.

  • Traitez les instructions SQL par lots si possible — Vous pouvez concaténer plusieurs instructions Transact-SQL dans une commande par lots pour récupérer plusieurs jeux de résultats ou effectuer plusieurs opérations DML dans une boucle réseau. Cette approche est particulièrement utile lors du traitement d'un grand nombre d'opérations INSERT consécutives.

  • Évitez la gestion des transactions basée sur l'application — Encapsuler des opérations de gestion des transactions (BEGIN TRAN, COMMIT/ROLLBACK) dans les procédures stockées peut réduire les boucles et les verrouillages du réseau.

Suivre les meilleures pratiques générales applicables aux bases de données sur site

Une fois que vous avez réduit la distance entre les données et les utilisateurs, et que vous avez réduit les boucles sur le réseau, l'étape suivante consiste à vous assurer que votre application suit les meilleures pratiques générales applicables aux bases de données sur site. En appliquant les meilleures pratiques et les recommandations connues à la couche d'accès aux données de votre application, ainsi que les meilleures pratiques applicables aux performances et à l'optimisation, vous devriez remarquer un effet de « multiplication » dans un environnement à latence élevée, comme le cloud.

Les meilleures pratiques générales pour l'interaction de la base de données avec des bases de données sur site incluent les recommandations suivantes :

  • Ouvrez une connexion tard et fermez-la le plus tôt possible — Pour réduire l'utilisation des ressources et minimiser les risques de limitation, ouvrez une connexion dans l'application uniquement là où le code a besoin de cette connexion. En outre, retournez la connexion au pool dès que le code a fini, en supprimant l'objet de connexion. (Il existe une exception à cette stratégie de retour, si vous devez effectuer d'autres tâches urgentes. Dans ce cas, retournez la connexion uniquement lorsque toutes les tâches urgentes ont été effectuées.)

  • Utilisez le regroupement de connexions — Au niveau du processus, les pools de connexions contiendront des connexions qui ciblent une même base de données et utilisent le même contexte de sécurité. Si possible, utilisez la même chaîne de connexion pour toutes les connexions qui ont les mêmes caractéristiques.

  • Récupérez uniquement les données dont vous avez besoin — Définissez avec soin votre liste SELECT et la clause WHERE. Cette approche permet de réduire l'utilisation de la bande passante réseau, et aussi d'indexer efficacement les performances de votre base de données.

  • Gérez les transactions aussi rapidement que possible, et évitez d'impliquer des ressources inutiles — Une création non optimale du modèle de données et des boucles excessives entre le code applicatif et les bases de données sont des problèmes courants, mais qui n'ont pas trop de conséquences sur les déploiements sur site, en raison de l'environnement de connectivité à faible latence. Il peut également être difficile de modifier ces applications pour les raisons suivantes :

    • Contraintes sur l'architecture existantes.

    • Création monolithique où l'accès aux données et la logique métier sont étroitement liés et interdépendants.

    • Certains aspects, tels que le traitement des données ligne par ligne, requis par la logique applicative elle-même, sont difficilement modifiables sans réécriture massive.

Outre ces meilleures pratiques générales, d'autres, liés aux technologies que vous utilisez dans votre application, sont recommandées. Par exemple, les applications qui utilisent le .NET Framework peuvent utiliser des technologies telles que ADO.NET, Entity Framework et les services WCF Data Services. Ces technologies permettent de réduire le temps de développement et offrent une souplesse supérieure pour l'implémentation de la couche d'accès aux données quel que soit le style d'application. En outre, elles conviennent bien à l'orientation d'un service car elles découplent les couches, offrent une flexibilité de schéma, utilisent des architectures de données ouvertes (par exemple, OData) et proposent une conception « déconnectée » par nature. Toutefois, en dépit de leurs avantages, elles peuvent générer le même type de problèmes rencontrés pour les applications héritées, comme les bavardages, si vous n'optimisez pas de façon appropriée la conception des données et les opérations (notamment, via une représentation optimale des données, l'utilisation du cache et les opérations liées aux données par lot, pour réduire les boucles inutiles).

Les sections suivantes décrivent quelques meilleures pratiques applicables à ces technologies, et l'emploi d'une programmation asynchrone sur vos applications Windows Azure.

Meilleures pratiques pour ODBC et JDBC

Pour les bibliothèques d'accès aux données, telles que ODBC et JDBC, où la prise en charge côté client des opérations intelligentes (telles que le tri, le filtrage, etc.) est limitée, vous pouvez toujours appliquer les techniques d'optimisation existantes, par exemple, en réduisant les opérations basées sur curseur et le traitement ligne par ligne. Lorsque les curseurs doivent être utilisés, utilisez les curseurs en lecture seule et les curseurs avant uniquement pour récupérer des valeurs, et les commandes SQL pour apporter des modifications aux données au lieu d'utiliser des mises à jour positionnées dans un curseur.

Meilleures pratiques pour ADO.NET

Avec ADO.NET, plusieurs optimisations peuvent être appliquées pour optimiser l'efficacité de votre code d'accès aux données :

  • Choisissez le mode d'exécution approprié avec SqlCommand — Par exemple, si vous avez besoin de récupérer uniquement une valeur scalaire, utilisez la méthode ExecuteScalar(), ou ExecuteNonQuery(), si vous n'avez pas besoin de récupérer de jeu de résultats

  • Utilisez la propriété UpdateBatchSize avec la classe SqlDataAdapter pour effectuer plusieurs opérations — Cela regroupe plusieurs commandes à mesure qu'elles sont transmises sur le réseau et réduit les boucles réseau.

  • Utilisez SqlDataAdapter pour implémenter des interactions directes avec la base de données en utilisant des procédures stockées pour les opérations SELECT, INSERT, UPDATE et DELETE.

  • Définissez la propriété SerializationFormat sur Binary lorsque vous utilisez des jeux de données comme cache côté client — Cela réduit la quantité de données transmises par voie filaire.

Meilleures pratiques pour Entity Framework

Lorsqu'il s'agit de développer l'accès aux données, l'Entity Framework s'avère très utile pour les raisons suivantes :

  • Il fournit un environnement de mappage objet-à-relation qui permet de réduire considérablement le temps de développement.

  • Il apporte davantage de souplesse en séparant la définition du schéma de la base de données physique de la représentation conceptuelle de vos données d'application.

  • Il fournit un jeu de services complets pour assurer la persistance.

  • Il réduit les boucles du réseau en chargeant les jeux de résultats depuis Base de données SQL Windows Azure dans des jeux d'objets dans la mémoire de l'application, et en les réutilisant hors ligne sans besoin d'interagir avec le serveur principal pour chaque opération.

Toutefois, comme pour tous les autres outils de programmation, l'Entity Framework peut générer des problèmes de performances si vous n'êtes pas suffisamment attentif aux interactions de la base de données. De plus, l'environnement Windows Azure amplifie ces problèmes de performances.

Pour optimiser l'utilisation de l'Entity Framework avec Base de données SQL Windows Azure, suivez les meilleures pratiques suivantes :

  • Désactivez explicitement le suivi de l'état des objets au niveau de l'ObjectStateManager pour les entités et les relations à la fois — Appliquez cette pratique si votre application n'a pas besoin de suivre l'état des objets car elle est utilisée en lecture seule.

  • Désactivez le chargement différé pour mieux contrôler l'interaction entre votre code et la base de données — Afin de réduire les boucles du réseau, vous pouvez précharger tout ce dont vous avez besoin dans une seule interaction. Lors du chargement et de la persistance des données dans la banque de données, plusieurs commandes peuvent être regroupées et appliquées en élargissant le contexte d'objet à l'aide de méthodes spécifiques.

  • Utilisez les procédures stockées pour les interactions entre banques de données lorsque cela est possible — Si vous ne pouvez pas utiliser les procédures stockées, utilisez des requêtes paramétrables et des vues indexées pour améliorer les performances.

  • Effectuez plusieurs opérations de base de données dans une seule boucle en intégrant des paramètres à valeur de table et en mappant des ensembles d'objets aux paramètres tabulaires des procédures stockées — Vous pouvez utiliser cette approche même si elle n'est pas prise en charge directement par les outils de conception.

  • Mappez plusieurs jeux de résultats aux objets dans une même opération lorsque cela est possible.

  • Mappez les jeux d'objets à la méthode System.Data.SqlClient.SqlBulkCopy.WriteToServer() pour les opérations massives d'insertion de données — La méthode SQLBulkCopy permet au moteur de base de données SQL Server et à Base de données SQL Windows Azure d'utiliser des optimisations de journalisation en bloc afin de réaliser des insertions volumineuses plus rapidement, dans la plupart des cas.

Pour plus d'informations, consultez Utiliser l'Entity Framework pour réduire la latence du réseau sur la Base de données SQL de Windows Azure.

Meilleures pratiques de programmation asynchrone

Certaines opérations de base de données, telles que les exécutions de commande, peuvent prendre beaucoup de temps. Dans ce cas, les applications à thread unique doivent bloquer d'autres opérations et attendre que la commande ait terminé avant de poursuivre les autres opérations. En revanche, en affectant une opération longue à un thread d'arrière-plan, vous permettez au thread de premier plan de rester actif pendant l'opération.

ADO.NET prend en charge les mêmes modèles de conception dans sa classe SqlCommand. En particulier, l'association des méthodes BeginExecuteNonQuery(), BeginExecuteReader() et BeginExecuteXmlReader() aux méthodes EndExecuteNonQuery(), EndExecuteReader() et EndExecuteXmlReader(), respectivement, fournit une prise en charge asynchrone.

Ces méthodes asynchrones ne vous dispensent pas d'appliquer toutes les optimisations et les meilleures pratiques mentionnées dans les sections précédentes. Toutefois, en permettant à d'autres opérations de s'exécuter en parallèle à la requête dans Base de données SQL Windows Azure, elles réduisent l'impact des longues opérations de base de données dans votre couche d'accès aux données.

Cela vous a-t-il été utile ?
(1500 caractères restants)
Merci pour vos suggestions.

Ajouts de la communauté

Afficher:
© 2014 Microsoft