SQL Server - Management Studio - Estadísticas de cliente - Tiempo de espera en las respuestas del servidor frente al tiempo de procesamiento del cliente

Tengo una consulta de ejecución lenta que he estado trabajando en la optimización.SQL Server - Management Studio - Estadísticas de cliente - Tiempo de espera en las respuestas del servidor frente al tiempo de procesamiento del cliente

Al consultar las estadísticas del cliente en Management Studio, el servidor tardaba unos 8 segundos en responder el servidor y aproximadamente 1 segundo en el tiempo de procesamiento del cliente.

Siempre he pensado que el tiempo de espera en las respuestas del servidor era el número para trabajar y el tiempo de procesamiento del cliente generalmente estaba relacionado con el ancho de banda o el tamaño de los datos grandes.

He realizado varios cambios en la consulta y ahora mi tiempo de espera en las respuestas del servidor es de alrededor de 250 ms, sin embargo, el tiempo de procesamiento del cliente ha aumentado a aproximadamente 9 segundos, lo que hace que el tiempo de ejecución total sea un poco más lento.

El conjunto de resultados devuelto es exactamente el mismo.

¿Alguien puede arrojar alguna luz sobre cuál es exactamente la diferencia entre estos dos números y qué podría causar tal resultado?

Fuente

2009-12-01 Robin Day

¿Cuál es la consulta que se está tratando de ejecutar? –

Después de una investigación adicional, el problema se estaba uniendo a una UDF con valores de tabla dentro de la consulta. Esto estaba causando un SOS_SCHEDULER_YIELD esperar cada fila de la consulta. Los parámetros de la tabla se corrigieron, así que acabo de llenar una tabla temporal con ella y me uní a eso. Ambas respuestas me ayudaron, por lo que elegir una aceptada es difícil. Se lo voy a dar a Remus cuando confirme mis pensamientos sobre las dos veces que estaba mirando y también dio los comandos exactos para obtener las esperas. –

'Tiempo de espera en el servidor responde' es el tiempo entre el último paquete de solicitud abandonó el cliente y el primer paquete de respuesta regresó de el servidor. El "tiempo de procesamiento del cliente" es el tiempo entre el primer paquete de respuesta y el último paquete de respuesta. Por cierto, no pude encontrar la documentación para respaldar estas afirmaciones, pero diría, en base a mis observaciones, que son una conjetura válida y educada.

Si ejecuta una consulta con un gran 'tiempo de espera en las respuestas del servidor', significa que el servidor tardó mucho tiempo en producir la primera fila. Esto es habitual en las consultas que tienen operadores que necesitan toda la sub consulta para evaluar antes de proceder (el ejemplo típico son los operadores de clasificación).

Por otro lado, una consulta con un muy pequeño 'tiempo de espera en las respuestas del servidor' significa que la consulta fue capaz de devolver la primera fila rápidamente. Sin embargo, un largo "tiempo de procesamiento del cliente" no necesariamente implica que el cliente haya pasado mucho tiempo procesando y el servidor haya sido bloqueado esperando en el cliente. Simplemente puede significar que el servidor continuó devolviendo filas del resultado y este es el tiempo que tomó hasta que se devolvió la última fila.

Lo que ve es el resultado de cambios en el plan de consulta que probablemente eliminaron un operador que bloqueaba la ejecución (probablemente un tipo) y el nuevo plan utiliza una estrategia diferente que produce el primer resultado más rápido (probablemente usa un índice eso garantiza la orden solicitada por lo que no necesito ningún tipo), pero en general duran más.

Si usted está preocupado por el cliente frenando el servidor (que puede suceder en grandes conjuntos de resultados), entonces usted debe investigar la wait_type en sys.dm_exec_requests (también información de sys.dm_os_tasks y sys.dm_os_workers es muy útil) para la sesión de ejecución de la consulta bajo investigación . Si no me equivoco, el servidor que espera en el tipo de espera del cliente es ASYNC_NETWORK_IO.También puede verificar el agregado sys.dm_os_wait_stats, restablecerlo usando DBCC SQLPERF("sys.dm_os_wait_stats" , CLEAR) luego ejecutar la consulta, ver cuánto tiempo suma el tipo de espera ASYNC_NETWORK_IO. Por supuesto, asegúrese de que no ocurra ninguna otra actividad en el servidor durante la prueba.

Fuente

2009-12-01 19:44:22

Eso fue lo que pensé que los significados eran para ellos también. La cuestión clave es que ambas consultas siguen teniendo el mismo orden de clasificación y realizando cambios de este tipo para incluir columnas que no están indexadas en todos los resultados, en el mismo resultado. Echaré un vistazo a algunos de los tipos de espera y redes. Gracias. Todavía estoy trabajando en un arnés de prueba para mostrar todo esto. Espero que tenga más sentido entonces. –

OK, encontré algunos artículos relacionados con este tema. Espero que puedan ser de ayuda. Debo decir que esto me ha abierto todos los nuevos tipos de puertas con respecto al ajuste de rendimiento de consultas.

SQL Server Wait Events: Taking the Guesswork out of Performance Profiling

Analysing Query Performance in SQL Server 2005

Display SQL Server database waits

INF: Client Effects on SQL Server Throughput

Fuente

2009-12-01 18:21:16

Gracias por esto, voy a leer. No puedo publicar la consulta que he estado ejecutando. Es bastante grande y no tendría mucho sentido sin muchos antecedentes. Estoy trabajando en un arnés de prueba simple que produce el mismo resultado. Lo publicaré tan pronto como haya terminado. –

Estas estadísticas se describen a continuación: http://msdn.microsoft.com/en-us/library/aa216969(v=SQL.80).aspx

Fuente

2011-10-04 08:17:35 nh1

Enlace roto. Pruebe http://msdn.microsoft.com/en-us/library/aa216969(v=SQL.80).aspx o http://technet.microsoft.com/en-us/library/aa216969(v=sql. 80) .aspx o busque en "Panel de estadísticas de ventana de consulta" –

SQL Server - Management Studio - Estadísticas de cliente - Tiempo de espera en las respuestas del servidor frente al tiempo de procesamiento del cliente

Respuesta

Cuestiones relacionadas