INF: Efectos de cliente en el rendimiento de SQL Server

Seleccione idioma Seleccione idioma
Id. de artículo: 180775 - Ver los productos a los que se aplica este artículo
Este artículo se ha archivado. Se ofrece "tal cual" y no se volverá a actualizar.
Expandir todo | Contraer todo

En esta página

Resumen

Evaluar áreas generales que afectan al rendimiento, más comúnmente considera aspectos son la velocidad del procesador, E/s de disco y memoria en el servidor. Aunque el rendimiento de estas partes del servidor son cruciales para el rendimiento adecuado, también debe considerar la latencia de red y tiempo de procesamiento de cliente como factores que también puede tener un impacto importante en el rendimiento global del sistema.

Este artículo describe las áreas de últimas y proporciona directrices para evaluar qué impacto que pueden tener en el servidor.

Más información

En el siguiente ejemplo se utilizará en todo el documento. Los pasos para las dos conexiones realizar la misma actualización con sólo una pequeña diferencia en la sintaxis de Transact-SQL.

Conexión 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
				

Conexión 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
				

Ida y vuelta de red

Conexión 1 requiere tres viajes al equipo de SQL Server:
  • Comenzar la transacción
  • Actualización
  • Confirmar y deshacer transacciones
Conexión 2 requiere un solo viaje para completar la actualización.

Cancelación de consulta

Tanto en DB-Library y en las API de ODBC admiten procesar una consulta asincrónica. Por ejemplo, DB-Library utiliza la función dbdataready para permitir que el cliente sondear el estado de finalización de la consulta.

En DB-Library, la función dbdataready está controlada por el valor de DataReadySleep. Para obtener información adicional acerca de la clave del registro de DataReadySleep, consulte en contacto con el siguiente artículo en Microsoft Knowledge Base:
159234: INF: cómo cambiar el valor de suspender utilizado por Dbdataready

Cómo afectan los tiempos de espera a los intervalos

De forma predeterminada, el valor de suspensión es 250 milisegundos.

Conexión 1 realiza tres viajes de ida a SQL Server. De forma predeterminada, el cliente encuentra un mínimo de 750 milisegundos de tiempo de espera, sin contar el tiempo para la transferencia real de la red. El tiempo de espera se calcula a partir (250 milisegundos * 3) = 750 milisegundos.

Conexión 2 hace que un solo viaje y encuentra un mínimo de 250 milisegundos de tiempo de espera, sin contar el tiempo de transferencia de red real.

Puede cambiar la velocidad de este ejemplo por un factor de tres, simplemente aprovechando la sintaxis de Transact-SQL y quitando dos red las acciones de ida y vuelta.

Cómo afectan los viajes de ida y vuelta en la red a otros usuarios

Conexión 1 contiene una transacción abierta para un mínimo de 500 milisegundos. Después de abrir la transacción, tarda 500 milisegundos para completar la actualización y, a continuación, confirmar o deshacer la transacción. Concurrencia de base de datos impide que otros usuarios tengan acceso a los registros que está modificando.

Conexión 2 mantiene la transacción abierta sólo tanto como sea necesario para completar la operación. En un equipo de procesador Pentium a 133 MHz ejecuta SQL Server y ISQL/w, se ven los intervalos siguientes.

Nota: La E/s de red final no se muestra en cualquiera de los ejemplos siguientes. Después de que ha completado la confirmación o deshacer los bloqueos se liberan pero la E/s final no es cuadran.
   Begin transaction                5 milliseconds
   Update                          20 milliseconds
   Commit/Rollback transaction      7 milliseconds
      TOTAL                        32 milliseconds
				

Conexión 2 se completará en aproximadamente 32 milisegundos, mientras que la conexión 1 requiere una ventana de procesamiento mucho mayor y amplía enormemente el tiempo de latencia de la transacción.
   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
				

Como se muestra anteriormente, el tiempo de red es un factor simple de tres. Sin embargo, el impacto de bloqueo que el ejemplo se impone en otros usuarios de la base de datos es un factor de 16 (532/32 = ~ 16).

Ahora supongamos que este sencillo ejemplo procede de un equipo portátil remoto conecta con un módem de 28,8. Además del 250 milisegundos retardo impuestas por el parámetro dbdatareadysleep es apreciable el tiempo empleado realmente transmitir la información a través del vínculo lento. Conexión 1 afectaría a otros usuarios de la base de datos por un factor aún mayor, mientras la conexión 2 sería afectado principalmente por la velocidad del equipo cliente. Una vez, se enviará el comando procesará en SQL Server en 32 milisegundos. El único usuario del sistema que experimenta una ralentización es el usuario remoto, que es el esperado, debido a un módem lento.

Tiempo de posposición de cliente

Tiempo de posposición de cliente es el período de tiempo que transcurre mientras el cliente procesa los resultados que recibió. Si observa nuevo 1 de la conexión, puede ver rápidamente cómo esto puede afectar al proceso. Si un extra 10 milisegundos son necesarios para que el cliente para tratar un conjunto de resultados, puede agregar otro milisegundos 30 a la hora de transacción general y el otro 20 milisegundos el tiempo de latencia de la transacción.

Vamos a cambiar de nuevo ejemplos. En este caso es una tabla de inventario desde un sistema en línea. Ha empleado meses desarrollar e instalar cuál debería ser el sistema de procesamiento de pedidos en línea más rápida de historial. Los usuarios pueden buscar, comprar y mantener un carro de la compra, entre otras opciones. Ésta es la tabla tbllnventory:
   tblInventory
      iProductID       int
      strTitle         varchar(50)
      strDescription   varchar(255)
      iSize            int
      iInStock         int
      iOnOrder         int
      iType            int
				

Deseo algunos cereales de compra. Sin embargo, me gustaría ver lo que está disponible. Se pueden definir cereales como tipo 2, por lo que la aplicación emite la consulta siguiente. En este ejemplo, la base de datos contiene 750 cereales-elementos relacionados.
   Select strTitle, strDescription, iSize, iInStock from tblInventory
   where iType = 2
				

SQL Server se compile y analizar la consulta y comience a devolver los resultados. Se adquieren bloqueos compartidos en las páginas apropiadas. Recuerde que compartidos bloqueos de actualización de bloque, insertar y eliminar operaciones.

Al mismo tiempo, puesto que la aplicación se utiliza por todo el país, seis otras personas están intentando realizar pedidos de cereales.

SQL Server rellena el primer paquete de datos tabulares (TDS) de la secuencia, envía al cliente y, a continuación, espera que el cliente procesar los resultados. Durante el tiempo que el cliente está procesando los resultados (tiempo de latencia de cliente), SQL Server continúa mantenga un bloqueo de página compartida en la página donde procesaba. Este bloqueo compartido puede bloquear un usuario que está intentando completar un pedido.

Parece una acción simple. Seleccionar un conjunto de resultados de SQL Server e insertar los valores en un cuadro de lista. Un equipo Pentium de 133 MHz puede agregar elementos de 750 a un cuadro de lista en sólo a través de un segundo. Deshabilitar el cuadro de lista al archivado toma sólo un tercio de segundo. Puede reducir considerablemente el tiempo de latencia de cliente, simplemente deshabilitando el cuadro de lista.

Es posible incluso que tienden a cambiar la operación para reducir aún más el bloqueo de selección. Limitar la exposición de bloqueo compartido cambiando la consulta a la siguiente.
   Insert * into #tblSelect from
   Select strTitle, strDescription, iSize, iInStock from tblInventory
				

   Select * from #tblSelect
				

La consulta está aislada en el servidor SQL Server y no iniciará devolver los resultados hasta que se han movido a la tabla temporal y se liberan todos los bloqueos compartidos de la tabla de inventario. Esto limita el tiempo que se mantienen bloqueos compartidos en la tabla de inventario para el tiempo necesario para que SQL Server mover los resultados a tempdb. El control es de nuevo con la base de datos y no en el cliente.

Otra forma de conseguir un comportamiento similar es que un cliente "inteligente". En lugar de rellenar un cuadro de lista, puede ser más rápido cargar una matriz. Sin embargo, todavía tiene dudas sobre está enlazando por rendimiento de la red. La tabla temporal es una solución mejor en estas situaciones.

Como puede ver, el cliente puede reproducir un rollo esencial en el rendimiento de base de datos. Debe tener especial cuidado cuando se trabaja con sistemas remotos y elaboración de informes. La cantidad de tiempo que el cliente tarda en procesar los resultados mientras mantiene bloqueos tiene el potencial de afectar el rendimiento de base de datos. Estos tipos de problemas pueden ser difícil ver los períodos de latencia pueden ser intervalos de 100 milisegundos y difíciles de ver con el procedimiento sp_who almacenados. Utilice un vínculo lento para ver rápidamente el comportamiento. Ejecutar la aplicación desde un vínculo RAS y vea qué es el comportamiento general como. También puede beneficiarse completa de la utilidad de seguimiento SQL para perfil cuidadosamente la aplicación.

Para obtener información adicional, consulte en contacto con los artículos siguientes en Microsoft Knowledge Base:
165951: INF: resultado de procesamiento para SQL Server

172117: INF: cómo código de Transact-SQL de perfil en procedimientos almacenados y desencadenadores

162361: INF: descripción y resolver problemas de bloqueo de SQL Server

167610: INF: evaluación de degradación del rendimiento de consultas

48712: INF: control de tiempo de espera correctamente en DB-Library

117143: INF: cuándo y cómo utilizar dbcancel() o sqlcancel()

Propiedades

Id. de artículo: 180775 - Última revisión: jueves, 30 de enero de 2014 - Versión: 3.0
La información de este artículo se refiere a:
  • Microsoft SQL Server 6.5 Standard Edition
Palabras clave: 
kbnosurvey kbarchive kbmt kbinfo KB180775 KbMtes
Traducción automática
IMPORTANTE: Este artículo ha sido traducido por un software de traducción automática de Microsoft (http://support.microsoft.com/gp/mtdetails) en lugar de un traductor humano. Microsoft le ofrece artículos traducidos por un traductor humano y artículos traducidos automáticamente para que tenga acceso en su propio idioma a todos los artículos de nuestra base de conocimientos (Knowledge Base). Sin embargo, los artículos traducidos automáticamente pueden contener errores en el vocabulario, la sintaxis o la gramática, como los que un extranjero podría cometer al hablar el idioma. Microsoft no se hace responsable de cualquier imprecisión, error o daño ocasionado por una mala traducción del contenido o como consecuencia de su utilización por nuestros clientes. Microsoft suele actualizar el software de traducción frecuentemente.
Haga clic aquí para ver el artículo original (en inglés): 180775

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