Una llamada grande frente a varias llamadas TSQL más pequeñas

Question

Tengo una pregunta de rendimiento ADO.NET/TSQL. Tenemos dos opciones en nuestra aplicación:

1) Una gran llamada a la base de datos con múltiples conjuntos de resultados, luego paso de código a través de cada conjunto de resultados y llenan mis objetos. Esto da como resultado un viaje de ida y vuelta a la base de datos.

2) Múltiples llamadas a bases de datos pequeñas.

Hay mucha más reutilización de código con la Opción 2, que es una ventaja de esa opción. Pero me gustaría obtener información sobre el costo del rendimiento. ¿Son dos viajes pequeños y redondos dos veces más lentos que un gran viaje de ida y vuelta a la base de datos, o es solo una pérdida de rendimiento pequeña, digamos del 10%? Estamos usando C# 3.5 y Sql Server 2008 con procedimientos almacenados y ADO.NET.

Answer 1

Creo que en parte dependerá de cuándo necesite los datos. Por ejemplo, si devuelve diez conjuntos de datos en un proceso grande, y ve los diez en la pantalla a la vez, luego vaya por ello. Pero si devuelve diez conjuntos de datos y el usuario solo puede hacer clic en las páginas para ver tres de ellos, el envío de los otros era un desperdicio de recursos de servidor y red. Si devuelve diez conjuntos de datos, pero el usuario realmente necesita ver los conjuntos siete y ocho solo después de realizar cambios en los conjuntos 5 y 6, entonces el usuario vería la información incorrecta si la devolviera demasiado pronto.

Si usa procs almacenados por separado para cada conjunto de datos llamado en un proceso maestro almacenado, no hay ninguna razón por la cual no pueda reutilizar el código en otra parte, así que la reutilización del código no es realmente un problema en mi mente.

Answer 2

Si le preocupa el rendimiento, intente una prueba de ambos y vea cuál funciona mejor.

Personalmente, prefiero el segundo método. Hace la vida más fácil para los desarrolladores, hace que el código sea más reutilizable y modulariza las cosas para que los cambios en el camino sean más fáciles.

Answer 3

Personalmente me gustaría ir con 1 viaje redondo más grande.

Esto definitivamente va a estar influenciado por la reutilización exacta del código de llamada, y cómo se puede refactorizar.

Pero como se mencionó, esto dependerá de su situación exacta, donde el mantenimiento frente al rendimiento podría ser un factor.

Answer 4

personalmente me gusta la segunda opción por la razón que declaró: la reutilización de código

Pero considere esto: para solicitudes pequeños la latencia puede ser más largo de lo que haces con la solicitud. Tienes que encontrar ese equilibrio correcto.

Answer 5

¿No optimizar el para un rendimiento hasta un arisess necesidad de hacerlo. Esto significa que debe analizar sus patrones de uso anticipados y determinar cuál será la frecuencia de uso típica para este proceso, y qué latencia de interfaz de usuario resultará del presente diseño. Si el usuario recibirá comentarios de la aplicación es de unos pocos (2-3) segundos, y la carga de la aplicación de este proceso no es una carga excesiva en la capacidad del servidor, entonces no se preocupe. Si otoh el usuario espera una cantidad de tiempo inaceptable para una respuesta (sujeto pero definitivamente mensurable) o si el servidor está sobrecargado, entonces es hora de comenzar la optimización. Y entonces, qué técnicas de optimización tendrán más sentido o serán más rentables, dependerá de lo que le indique su análisis del problema.

Por lo tanto, mientras tanto, concéntrese en la facilidad de mantenimiento. Eso significa, en su caso, reutilización de código

Answer 6

Como desarrollador ADO.Net, su trabajo es hacer que el código sea lo más correcto, claro y fácil de mantener posible. Esto significa que debe separar sus preocupaciones.

El trabajo de la tecnología de conexión de SQL Server es rápido.

Si implementa una aplicación correcta, clara y fácil de mantener que resuelve los problemas de negocios, y resulta que el acceso a la base de datos es el mayor cuello de botella que impide que el sistema funcione dentro de límites aceptables, entonces, y solo comienza a persistir maneras de solucionar el problema. Esto puede incluir o no la consolidación de consultas de bases de datos.

Answer 7

Parece un poco obvio, pero solo envía lo que necesitas en una sola llamada.

Por ejemplo, tenemos un programa almacenado "getStuff" para la presentación. El proceso "updateStuff" llama al procedimiento "getStuff" y el método del contenedor del cliente para "updateStuff" espera el tipo "Thing". Así que un viaje redondo.

Los servidores de chatty son una cosa que previene con muy poco esfuerzo. Luego, puede ajustar el código de base de datos o el código de cliente según sea necesario ... pero es difícil calcular los recorridos de ida y vuelta más tarde, sin importar qué tan rápido se ejecute su código. En el extremo, ¿qué pasa si su servidor web está en un país diferente al servidor de su base de datos ...?

Editar: es interesante notar que los chicos de SQL (HLGEM, Astander, yo) diciendo "un viaje" y los tipos de clientes que dicen "múltiple, la reutilización de código" ...

Answer 8

estoy luchando con este problema por mí mismo . Y aún no tengo una respuesta, pero tengo algunas ideas.

Después de haber revisado las respuestas dadas por otros hasta este punto, todavía hay una tercera opción.

En mi aplicación, se hacen alrededor de diez o doce llamadas al servidor para obtener los datos que necesito. Algunos de los campos de datos son varchar max y varbinary max fields (imágenes, documentos de gran tamaño, videos y archivos de sonido). Todas mis llamadas son sincrónicas, es decir, mientras se solicitan los datos, el usuario (y el programa del lado del cliente) no tiene más remedio que esperar. Es posible que solo quiera leer o ver los datos, que solo tienen sentido cuando todo está allí, no solo parcialmente. El proceso, creo, es más lento de esta manera y estoy en el proceso de desarrollar un enfoque alternativo que se basa en llamadas asincrónicas al servidor desde un libaray de DLL que plantea eventos al cliente para anunciar el progreso al cliente. El cliente está programado para manejar los eventos DLL y establecer una variable en el lado del cliente indicando que las llamadas chich se han completado. El programa cliente puede entonces hacer lo que debe hacer para preparar los datos recibidos en la llamada n. ° 1 mientras la DLL avanza de forma asíncrona para obtener los datos de la llamada n. ° 2. Cuando el cliente está listo para procesar los datos de la llamada n. ° 2, debe verificar el estado y esperar para proceder si es necesario (espero que sea una espera corta o ninguna). De esta manera, tanto el software del servidor como el del cliente realizan el trabajo de una manera más eficiente.