2010-01-26 15 views
9

He leído muchos artículos sobre el rendimiento de linq a sql. El resultado que obtuve es que es más lento de lo normal (biblioteca DAL o Microsoft Enterprise). Más lento para las operaciones de lectura y escritura, incluso después del ajuste del rendimiento como desactivar el seguimiento de objetos y otros trucos. Sé que tiene prons como desarrollo rápido, código limpio, etc., pero ¿qué pasa con el rendimiento?debería linq to sql ser utilizado para sitios web que tienen alto tráfico

¿Qué ocurre si utilicé solo operaciones de lectura?

Por favor, den sus sugerencias.

+0

+1 No creo que su LINQ a SQL como un todo, sino que es tan profundo, y tan fácil de hacer mal. Un uso mal entendido de una propiedad de colección en un ciclo puede conducir a grandes problemas de rendimiento rápidamente. –

Respuesta

8

Parece que funciona bastante bien para stackoverflow ;-p Especialmente si usa compiled queries, es poco probable que sea su cuello de botella, comparado (por ejemplo) con el diseño de DB apropiado y buscando las columnas/filas correctas, y evitando n + 1 cargando

+0

@Gravel && @Byers. una pregunta. supongamos que tenemos 3 servidores. 1 para lectura, 1 para escritura y el otro es un servidor de replicación. entonces si uso linq para operaciones de lectura y para operación de escritura, uso las consultas a mano. ¿Es esta la mejor solución? o hay alguna otra mejor solución. lo que sugiere – Adeel

+0

@Adeel - db servidores o servidores de aplicaciones? Parece que te refieres al servidor db, pero no estoy seguro de que la API * específica * de acceso a datos utilizada suponga una gran diferencia (en comparación con las diferentes configuraciones db) –

+0

Siempre puedes usar SP/UDF para leer , también (a través de L2S) ... –

4

Para operaciones de lectura LINQ To SQL debe ser más o menos tan rápido como escribir directamente el SQL porque eso es exactamente lo que hace. La sobrecarga de crear el SQL no debería ser notoria. Puede haber algunas consultas que no sean tan óptimas como si hubiera escrito la consulta a mano, pero en mi experiencia lo hace muy bien en la mayoría de los casos.

Para las actualizaciones masivas, LINQ to SQL es generalmente más lento porque maneja las filas de a una por vez. No puede hacer algo como UPDATE Foo SET x = 0 WHERE id BETWEEN 100 AND 200 en LINQ to SQL sin obtener todas las filas. Actualmente es mejor escribir el SQL a mano para este tipo de operación.

3

Las actualizaciones y eliminaciones son donde LINQ to SQL sufre actualmente ya que se genera una declaración separada para cada objeto afectado.

Dicho esto, esta publicación de blog detalla cómo obtener ambas operaciones a una declaración, lo que debería ayudar a mejorar el rendimiento: Batch Updates and Deletes with LINQ to SQL.

Las consultas compiladas también serán útiles para las consultas de uso frecuente, especialmente aquellas donde los parámetros se utilizan para obtener resultados específicos. También puede encontrar esta publicación útil: 10 Tips to Improve your LINQ to SQL Application Performance.