2010-01-26 2 views
9

Я прочитал много статей о производительности linq для sql. Результат, который я получил, медленнее обычного (DAL или Microsoft Enterprise). Медленнее для операций чтения и записи даже после настройки производительности как отключить ObjectTracking и другие трюки. Я знаю, что у него есть прозу, такие как быстрая разработка, чистый код и т. Д., Но как насчет производительности.следует использовать linq для sql для сайтов с высоким трафиком

Что делать, если я использовал только для операций чтения.

Просьба представить свои предложения.

+0

+1 Я не думаю, что его LINQ для SQL в целом, но вместо этого тот факт, что он настолько глубок, и так легко сделать неправильно. Непонятое использование свойства коллекции в цикле может привести к большим проблемам с производительностью. –

ответ

8

Кажется, что он работает достаточно хорошо для stackoverflow; -p Особенно, если вы используете compiled queries, это вряд ли будет вашим узким местом, сравнимым (например) с соответствующим дизайном БД и выбором правильных столбцов/строк и избегая n + 1 загрузка.

+0

@Gravel && @Byers. один вопрос. предположим, что у нас есть 3 сервера. 1 для чтения, 1 для записи, а другой - сервер репликации. поэтому, если я использую linq для операций чтения и для операции записи, я использую запросы вручную. Это лучшее решение? или есть другое лучшее решение. что вы предлагаете – Adeel

+0

@Adeel - серверы db или серверы приложений? Похоже, что вы имеете в виду сервер db, но я не уверен, что используемый API * для доступа к данным * будет иметь огромное значение (по сравнению с различными настройками db). –

+0

Вы всегда можете использовать SPs/UDF для чтения , также (через L2S) ... –

4

Для операций чтения LINQ To SQL должен быть примерно таким же быстрым, как непосредственно запись SQL, потому что это именно то, что он делает. Накладные расходы на создание SQL не должны быть заметны. Могут быть несколько запросов, которые не будут такими же оптимальными, как если бы вы написали запрос вручную, но по моему опыту он очень хорошо работает в большинстве случаев.

Для массовых обновлений LINQ To SQL обычно медленнее, поскольку он обрабатывает строки по одному. Вы не можете сделать что-то вроде UPDATE Foo SET x = 0 WHERE id BETWEEN 100 AND 200 в LINQ to SQL, не выбирая все строки. В настоящее время лучше всего написать SQL вручную для этого типа операции.

3

Обновления и удаления - это то, где LINQ to SQL в настоящее время страдает, поскольку для каждого затронутого объекта создается отдельный оператор.

При этом в этом блоге подробно описывается, как получить обе операции до 1 инструкции, что должно помочь повысить производительность: Batch Updates and Deletes with LINQ to SQL.

Скомпилированные запросы также будут полезны для часто используемых запросов, особенно тех, где параметры используются для получения конкретных результатов. Вы также можете найти это сообщение полезным: 10 Tips to Improve your LINQ to SQL Application Performance.

Смежные вопросы