INF: Client Effects sur le débit du serveur SQL

Traductions disponibles Traductions disponibles
Numéro d'article: 180775 - Voir les produits auxquels s'applique cet article
Cet article a été archivé. Il est proposé « en l'état » et ne sera plus mis à jour.
Agrandir tout | Réduire tout

Sommaire

Résumé

Lors de l'évaluation de zones générales qui affectent les performances, les plus couramment considéré aspects vitesse du processeur, les e/S disque et la mémoire sur le serveur. Même si les performances de ces parties du serveur sont cruciaux pour la bonne exécution, vous devez également prendre en compte latence du réseau et le temps de traitement client en tant que facteurs peuvent également avoir un impact majeur sur les performances globales du système.

Cet article traite des dernier et fournit des instructions permettant d'évaluer quelle mesure ils peuvent avoir sur le serveur.

Plus d'informations

L'exemple suivant sera utilisé tout au long du document. Les étapes à suivre pour les deux connexions effectuer la mise à jour même avec juste une petite différence dans la syntaxe Transact-SQL.

Connexion 1

use pubs
go
select convert(char(30), GetDate(), 9) "Start Time"
go

            Begin transaction

   Go   ==>   Send to SQL Server and process results

            Update authors set au_lname = au_lname

   Go   ==>   Send to SQL Server and process results

Commit / Rollback transaction

   Go   ==>   Send to SQL Server and process results

select convert(char(30), GetDate(), 9) "End Time"
go
				

Connexion 2

use pubs
go
select convert(char(30), GetDate(), 9) "Start Time"
go
begin transaction
if(0 = @@ERROR)
begin
   update authors set au_lname = au_lname
   if(0 = @@ERROR)
   begin
      commit transaction
   end
   else
   begin
      rollback transaction
   end
end
go    ==>   Send to SQL Server and process results
select convert(char(30), GetDate(), 9) "End Time"
go
				

Réseau Round Trips

Connexion 1 nécessite trois aller-retour vers l'ordinateur SQL Server :
  • Begin transaction
  • Mise à jour
  • COMMIT / ROLLBACK transaction
Connexion 2 nécessite un seul voyage pour terminer la mise à jour.

Annulation de requête

La DB-Library et les API ODBC prennent en charge le traitement de requête asynchrone. Par exemple, DB-Library utilise la fonction dbdataready pour autoriser le client à interroger l'état d'achèvement de la requête.

Dans DB-Library, la fonction dbdataready est contrôlée par la valeur DataReadySleep. Pour plus d'informations sur la clé de Registre DataReadySleep, consultez l'article suivant dans la base de connaissances Microsoft :
159234: INF: How to change la valeur de veille utilisée par Dbdataready

Influence le minutage des périodes de veille

Par défaut, la valeur mise en veille est 250 millisecondes.

Connexion 1 crée trois voyages rondes à SQL Server. Par défaut, le client rencontre un minimum de 750 millisecondes du temps d'attente, sans compter le temps de transfert réseau réelle. Le temps d'attente est calculé à partir de (250 millisecondes * 3) = 750 millisecondes.

Connexion 2 fait un seul voyage et rencontre un minimum de 250 millisecondes du temps d'attente, sans compter le temps de transfert réseau réelle.

Vous pouvez modifier la vitesse de cet exemple par un facteur de trois, simplement en tirant parti de la syntaxe Transact-SQL et en supprimant deux réseau allers et retours.

Influence des allers et retours réseau sur les autres utilisateurs

Connexion 1 conserve une transaction ouverte pour un minimum de 500 millisecondes. Une fois que la transaction est ouverte, il faut 500 millisecondes pour terminer la mise à jour puis de valider ou d'annuler la transaction. Concurrence d'accès de base de données empêche les autres utilisateurs d'accéder aux enregistrements que vous modifiez.

Connexion 2 conserve la transaction ouverte uniquement aussi longtemps que nécessaire pour terminer l'opération. Sur un ordinateur monoprocesseur Pentium 133 MHz exécutant SQL Server et ISQL/w, le minutage suivant s'affichent.

Remarque : Les e/S réseau finale ne figure pas dans un des exemples suivants. Une fois la validation ou annulation terminée les verrous sont libérés mais les e/S finale est pointée pas.
   Begin transaction                5 milliseconds
   Update                          20 milliseconds
   Commit/Rollback transaction      7 milliseconds
      TOTAL                        32 milliseconds
				

Connexion 2 terminera en millisecondes environ 32, considérant que la connexion 1 nécessite une fenêtre de traitement beaucoup plus grande étend considérablement le temps de latence de transaction.
   Begin transaction                5 milliseconds
   Network I/O                    250 milliseconds
   Update                          20 milliseconds
   Network I/O                    250 milliseconds
   Commit/Rollback transaction      7 milliseconds
      TOTAL                       532 milliseconds
				

Comme indiqué précédemment, l'heure du réseau est un facteur simple de trois. Toutefois, l'impact de verrouillage de l'exemple impose aux autres utilisateurs de la base de données est un facteur de 16 (532/32 = ~ 16).

Maintenant supposons que cet exemple simple est d'un ordinateur portable distant connexion avec un modem 28,8 Kbits/s. En plus de délai de 250 millisecondes imposées par le paramètre dbdatareadysleep, le temps nécessaire à en fait transmettre les informations sur la liaison lente est sensible. Connexion 1 affecterait autres utilisateurs de la base de données par un facteur encore plus grand, alors que la connexion 2 serait principalement affectés par la vitesse de l'ordinateur client. La commande est envoyée une seule fois, traitée au niveau du serveur SQL Server en 32 millisecondes. Le seul utilisateur du système qui rencontre un ralentissement est l'utilisateur distant, qui est comme prévu, en raison de modem lent.

Client Lag Time

Retard du client correspond à la période de temps devant s'écouler pendant que le client traite les résultats qu'il reçues. Si vous regardez à nouveau connexion 1, vous pouvez voir rapidement comment cela peut affecter le processus. Si un extra 10 millisecondes sont nécessaires pour que le client de gérer un jeu de résultats, vous pouvez ajouter un autre 30 millisecondes le temps global de la transaction et un autre 20 millisecondes au temps de latence de transaction.

Nous allons activer de nouveau exemples. Dans ce cas, il y a une table d'inventaire à partir d'un système en ligne. Vous avez passé mois développement et l'installation de ce qui doit être le système de traitement plus rapide des commandes en ligne dans l'historique. Les utilisateurs peuvent rechercher, acheter et conserver un panier d'achat, entre autres options. Il s'agit de la table tbllnventory :
   tblInventory
      iProductID       int
      strTitle         varchar(50)
      strDescription   varchar(255)
      iSize            int
      iInStock         int
      iOnOrder         int
      iType            int
				

Je veux acheter certaines céréales. Cependant, j'aimerais examiner le contenu. Nous CAN définir céréales de la frappe 2, de sorte que l'application émet la requête suivante. Dans cet exemple, la base de données contient 750 céréales des éléments.
   Select strTitle, strDescription, iSize, iInStock from tblInventory
   where iType = 2
				

Le serveur SQL compiler et analyser la requête et ensuite commencer à renvoyer les résultats. Verrous partagés sont posés sur les pages appropriées. N'oubliez pas que partagées mise à jour du bloc de verrous, insertion et opérations de suppression.

En même temps, car votre application est utilisée au niveau national, six autres personnes tentez de passer des commandes de céréales.

SQL Server remplit le premier paquet de flux (TDS) de données tabulaires, envoie au client et puis attend que le client traiter les résultats. Lors de la période que le client est en train de traiter les résultats (temps de latence de client), SQL Server continue à maintenir un verrouillage de page partagée dans la page où il était en train. Ce verrou partagé peut bloquer un utilisateur qui tente d'exécuter une commande.

Il semble être une action simple. Sélectionner un jeu de résultats à partir de SQL Server et insérer les valeurs dans une zone de liste. Un ordinateur Pentium 133 MHz pouvez ajouter des éléments de 750 à une zone de liste dans simplement une seconde. Désactivation de la zone de liste tout en archivant prend uniquement un tiers de seconde. Vous pouvez considérablement réduire le temps de latence de client en désactivant simplement la zone de liste.

Vous pouvez même être tenté de modifier l'opération de sélection pour réduire encore le verrouillage. Limiter l'exposition de verrou partagé en modifiant la requête à la suivante.
   Insert * into #tblSelect from
   Select strTitle, strDescription, iSize, iInStock from tblInventory
				

   Select * from #tblSelect
				

La requête est isolée sur le serveur SQL Server et ne démarrera pas le renvoi de résultats jusqu'à ce qu'ils ont été déplacés vers la table temporaire et tous les verrous partagés sont libérés de la table des stocks. Cela limite la durée des verrous partagés conservés sur la table des stocks du temps nécessaire pour SQL Server déplacer les résultats dans tempdb. Le contrôle est à nouveau avec la base de données et non sur le client.

Une autre méthode pour accomplir un comportement similaire consiste en faire un client «intelligente». Au lieu de remplissage d'une zone de liste, il peut être plus rapide pour charger un tableau. Toutefois, vous avez toujours des questions concernant être tenue par le débit du réseau. La table temporaire est une meilleure solution dans ces situations.

Comme vous pouvez le voir, le client peut jouer un rouleau pivot dans le débit de base de données. Vous devez être particulièrement prudent lorsque vous travaillez avec des systèmes distants et de reporting. La durée pendant laquelle le client nécessaire au traitement des résultats tout en maintenant des verrous est susceptible d'avoir un impact sur le débit de base de données. Ces types de problèmes peuvent être difficile de voir les périodes de latence est peut-être minutages de 100 millisecondes et difficile à voir avec la procédure sp_who stockées. Utilisez une liaison lente pour afficher rapidement le comportement. Exécutez l'application à partir d'un lien RAS et connaître le comportement global comme. Vous pouvez également de tirer parti de l'utilitaire de SQL Trace Profiler soigneusement l'application.

Pour plus d'informations, consultez les articles suivants dans la base de connaissances Microsoft :
165951: INF: résultat de traitement pour SQL Server

172117: INF: How to Code Transact-SQL de profil dans des procédures stockées et déclencheurs

162361: INF: compréhension et résolution des problèmes de blocage de SQL Server

167610: INF: évaluation de dégradation de performances de requête

48712: INF: gestion des délais d'attente correctement dans DB-Library

117143: INF: quand et comment utiliser dbcancel() ou sqlcancel()

Propriétés

Numéro d'article: 180775 - Dernière mise à jour: lundi 3 février 2014 - Version: 3.0
Les informations contenues dans cet article s'appliquent au(x) produit(s) suivant(s):
  • Microsoft SQL Server 6.5 Édition Standard
Mots-clés : 
kbnosurvey kbarchive kbmt kbinfo KB180775 KbMtfr
Traduction automatique
IMPORTANT : Cet article est issu du système de traduction automatique mis au point par Microsoft (http://support.microsoft.com/gp/mtdetails). Un certain nombre d?articles obtenus par traduction automatique sont en effet mis à votre disposition en complément des articles traduits en langue française par des traducteurs professionnels. Cela vous permet d?avoir accès, dans votre propre langue, à l?ensemble des articles de la base de connaissances rédigés originellement en langue anglaise. Les articles traduits automatiquement ne sont pas toujours parfaits et peuvent comporter des erreurs de vocabulaire, de syntaxe ou de grammaire (probablement semblables aux erreurs que ferait une personne étrangère s?exprimant dans votre langue !). Néanmoins, mis à part ces imperfections, ces articles devraient suffire à vous orienter et à vous aider à résoudre votre problème. Microsoft s?efforce aussi continuellement de faire évoluer son système de traduction automatique.
La version anglaise de cet article est la suivante: 180775
L'INFORMATION CONTENUE DANS CE DOCUMENT EST FOURNIE PAR MICROSOFT SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE. L'UTILISATEUR ASSUME LE RISQUE DE L'UTILISATION DU CONTENU DE CE DOCUMENT. CE DOCUMENT NE PEUT ETRE REVENDU OU CEDE EN ECHANGE D'UN QUELCONQUE PROFIT.

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com