Accélérer et optimiser les performances

10 minutes

Afin d’offrir des performances cohérentes, vous devez bien comprendre les options qui vous permettent d’accélérer et de régler les performances d’Azure SQL. Vous devez notamment comprendre comment mettre à l’échelle la capacité du processeur, augmenter les performances des E/S, configurer la mémoire et les workers, améliorer la latence des applications et appliquer les bonnes pratiques standard pour le réglage de SQL Server.

Mettre à l’échelle la capacité de l’UC

Vous devrez peut-être mettre à l’échelle le nombre de processeurs en fonction de vos besoins en ressources. Pour un environnement local, vous devez reconfigurer une machine virtuelle, modifier le matériel et même migrer votre base de données. Azure SQL vous permet d’effectuer cette opération sans aucune migration de votre part. Vous pouvez utiliser le portail, T-SQL, Azure CLI ou les API REST afin d’effectuer un scale-up ou un scale-down du nombre de vCores pour votre déploiement.

Un temps d’arrêt est généralement nécessaire, mais il peut être très rapide pour Azure SQL Database sans migration. Les déploiements Hyperscale vous permettent d’effectuer un scale-up en temps constant, indépendamment de la taille des données, et les déploiements serverless autorisent la mise à l’échelle automatique en fonction de la demande du processeur.

Remarque

La mise à l’échelle d’Azure SQL Managed Instance peut prendre beaucoup de temps, mais elle ne nécessite aucune migration.

Performances d’E/S

Les performances d’e/s peuvent être essentielles pour une application de base de données. Azure SQL élimine le placement physique des fichiers, mais il existe des méthodes pour vous assurer que vous disposez des performances d’E/S dont vous avez besoin.

Les opérations d’entrée/sortie par seconde (IOPS) peuvent être importantes pour votre application. Vérifiez que vous avez choisi le bon niveau de service et les vCores appropriés pour vos besoins d’IOPS. Apprenez à mesurer les IOPS pour vos requêtes locales si vous effectuez une migration vers Azure. Si vous avez des restrictions sur les IOPS, vous pouvez voir des attentes d’E/S longues. Dans le modèle d’achat des vCores, vous pouvez faire un scale-up des vCores, ou passer au modèle Critique pour l’entreprise ou Hyperscale si vous n’avez pas assez d’IOPS. Pour les charges de travail de production, en cas d’utilisation de DTU, nous vous recommandons de passer au niveau Premium.

La latence d’e/s est un autre composant clé pour les performances d’e/s. Pour une latence d’e/s plus rapide pour les Azure SQL Database, envisagez Critique pour l’entreprise ou Hyperscale. Pour augmenter la latence d’E/S pour SQL Managed Instance, passez à Critique pour l’entreprise ou augmentez la taille de fichier ou le nombre de fichiers de la base de données. L’amélioration de la latence du journal des transactions peut nécessiter l’utilisation de transactions multi-instructions.

Augmenter la mémoire ou les Workers

Le fait de disposer de suffisamment de mémoire ou de workers peut être important pour votre application et le déploiement. Pour Azure SQL Database, mettez à l’échelle vCores pour obtenir des limites de mémoire ou des rôles de travail plus élevés. Pour SQL Managed Instance, effectuez un scale-up des vCores pour avoir des limites de mémoire supérieures. À l’heure actuelle, SQL Managed Instance prend également en charge l’augmentation des workers avec « max worker threads ».

Amélioration de la latence de l'application

Même si vous configurez votre déploiement pour tous vos besoins en ressources, les applications peuvent introduire des problèmes de latence. Veillez à suivre ces meilleures pratiques avec les applications Azure SQL :

Utiliser un type de connexion de redirection à la place d’un proxy.
Optimiser les applications « bavardes » en utilisant des procédures stockées ou en limitant le nombre d’allers-retours des requêtes au moyen de différentes techniques (comme des lots).
Optimiser les transactions en les regroupant (par opposition à des transactions de type singleton).

Ajuster comme s’il s’agit de SQL Server

Azure SQL est toujours SQL Server. Il n’y a presque jamais de substituts pour vous permettre de régler vos requêtes SQL Server et d’examiner les éléments suivants :

Conception d'index correct
Utilisation de lots
Utilisation des procédures stockées
Paramétrisation des requêtes pour éviter la mise en cache d’un trop grand nombre de requêtes ad hoc
Traitement rapide et correct des résultats dans votre application