Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Многопоточность, Entity Framework и SQL  [new]
ProgED
Member

Откуда:
Сообщений: 3
Столкнулся я со следующей проблемой - мое приложение, несмотря на обращение к MS SQL из нескольких потоков, ведет себя так, как будто поток всего один.

Поясню.

Есть одна БД на SQL-сервере, одно .NET приложение-сервер, использующее Entity Framework и куча программ-клиентов, обращающихся к этому приложению.

В качестве примера приведу ситуацию:
К .NET-серверу обращаются, скажем, 5 клиентов одновременно с целью получить данные из БД.
.NET-сервер для каждого клиента создает новый поток и далее вся работа по предоставлению информации для клиента идет изолированно каждая в своем потоке.

Проблема в том, что .NET-сервер вместо того, чтобы получить все данные с SQL одновременно для 5 клиентов, ставит их в очередь!
Мне не понятно, является ли это особенностью работы Entity Framework или можно как-нибудь настроить SQL-сервер.

Может кто-нибудь знает как заставить SQL-сервер обрабатывать несколько различных запросов одного приложения, но с несколькими потоками?

Или кто-нибудь сталкивался с подобной проблемой и решил ее по-другому? Буду рад любому совету/опыту.
23 янв 13, 13:02    [13814786]     Ответить | Цитировать Сообщить модератору
 Re: Многопоточность, Entity Framework и SQL  [new]
Jovanny
Member

Откуда:
Сообщений: 1196
Скорее всего, так Ваш .Net сервер спроектирован.
23 янв 13, 13:08    [13814842]     Ответить | Цитировать Сообщить модератору
 Re: Многопоточность, Entity Framework и SQL  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 37228
SQL cервер никак не может влиять на логику работы клиентских приложений.

Сообщение было отредактировано: 23 янв 13, 13:13
23 янв 13, 13:13    [13814897]     Ответить | Цитировать Сообщить модератору
 Re: Многопоточность, Entity Framework и SQL  [new]
iiyama
Member

Откуда:
Сообщений: 642
Вам здесь быстрее ответят
23 янв 13, 13:16    [13814929]     Ответить | Цитировать Сообщить модератору
 Re: Многопоточность, Entity Framework и SQL  [new]
ProgED
Member

Откуда:
Сообщений: 3
Я вот думаю может проблема в том, что .NET сервер общается с SQL с помощью одного пользователя. Что если создать несколько пользователей SQL и по кругу их подставлять для каждого потока?

Просто слышал что драйвер SQL при совпадении всех параметров строки подключения не создает новое соединение для клиента, а использует одно и то же...
23 янв 13, 13:23    [13814984]     Ответить | Цитировать Сообщить модератору
 Re: Многопоточность, Entity Framework и SQL  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 37228
ProgED
Просто слышал что драйвер SQL при совпадении всех параметров строки подключения не создает новое соединение для клиента, а использует одно и то же...
А я слышал, что земля плоская.
23 янв 13, 13:25    [13814999]     Ответить | Цитировать Сообщить модератору
 Re: Многопоточность, Entity Framework и SQL  [new]
Glory
Member

Откуда:
Сообщений: 104751
ProgED
Что если создать несколько пользователей SQL и по кругу их подставлять для каждого потока?

И что будет если у меня число пользователей - миллион ?
Мне миллион пользователей в SQL создавать ?

ProgED
Просто слышал что драйвер SQL при совпадении всех параметров строки подключения не создает новое соединение для клиента, а использует одно и то же...

слышал звон, но не знаю, где он

Сообщение было отредактировано: 23 янв 13, 13:27
23 янв 13, 13:26    [13815009]     Ответить | Цитировать Сообщить модератору
 Re: Многопоточность, Entity Framework и SQL  [new]
VSVLAD
Member

Откуда: Краснодар
Сообщений: 1391
ProgED,

Потоки создаёте через ТредПул? тогда может быть что потоки в ожидание идут.
23 янв 13, 13:27    [13815014]     Ответить | Цитировать Сообщить модератору
 Re: Многопоточность, Entity Framework и SQL  [new]
super-code
Member

Откуда:
Сообщений: 244
ProgED, не знаю, как с Entity Framework, но если рабоать напрямую, то в каждом потоке должен создаваться свой SqlConnection. Скорее всего в Entity Framework есть что-то типа этого, так вот такая сущность должна быть своя для каждого потока.
23 янв 13, 15:05    [13815817]     Ответить | Цитировать Сообщить модератору
 Re: Многопоточность, Entity Framework и SQL  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31865
ProgED
Мне не понятно, является ли это особенностью работы Entity Framework или можно как-нибудь настроить SQL-сервер.
Оба предположения неправильные, это просто ваш код так написан.
23 янв 13, 16:36    [13816768]     Ответить | Цитировать Сообщить модератору
 Re: Многопоточность, Entity Framework и SQL  [new]
LogrusAS
Member

Откуда: Киев
Сообщений: 195
Ну по поводу драйвера я бы не был столь категоричен. Другое дело что в разных случаях он ведет себя по разному.
Речь в том "звоне" видимо шла об pool подключений.
В OLEDB точно была такая штука. Подключение через udl файл по определению шло через пул подключений. Причем количество подключений было зашито намертво в систему. Хотя добавление в реестр нового недокументированного параметра могло и изменить количество сессий.
Было у меня на обслуживании одно приложение которое работало через много подключений "подключился, получил данные, отключился" и увеличение количества сессий катастрофически ускоряло его работу.

Зато когда я начал использовать BulkInsert (а в OLEDB он не так уж прост как в NET) то вставка не выполнялась с сообщением о невозможности делать BulkInsert из сессии где проводятся другие операции! Хотя Connection создавался новый, но из того же udl файла. Решилось просто. После подключения через udl, из созданного подключения бралась строка подключения и создавался объект Connection уже другим методом, через строку подключения.

В NET я тоже натыкался на похожую проблему. Но в NET SqlBulkCopy класс реализован сразу правильно. Он требует для создания именно строку подключения.

Как там в Entity Framework я не знаю, но вполне себе может быть и так.

Но разбираться придется самому. Вашего кода то никто не видит. :-)
23 янв 13, 17:38    [13817158]     Ответить | Цитировать Сообщить модератору
 Re: Многопоточность, Entity Framework и SQL  [new]
LogrusAS
Member

Откуда: Киев
Сообщений: 195
Да, и SQL Server тут совсем не причем, его не настроить так как Вам нужно.
23 янв 13, 17:39    [13817161]     Ответить | Цитировать Сообщить модератору
 Re: Многопоточность, Entity Framework и SQL  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31865
LogrusAS
Ну по поводу драйвера я бы не был столь категоричен. Другое дело что в разных случаях он ведет себя по разному.
Речь в том "звоне" видимо шла об pool подключений.
В OLEDB точно была такая штука. Подключение через udl файл по определению шло через пул подключений. Причем количество подключений было зашито намертво в систему. Хотя добавление в реестр нового недокументированного параметра могло и изменить количество сессий.
Было у меня на обслуживании одно приложение которое работало через много подключений "подключился, получил данные, отключился" и увеличение количества сессий катастрофически ускоряло его работу.
Ну это же не вопрос распаралеливания. Просто будет замедление, получение соединения из пула и создание нового отличаются по скорости, и это совершенно не зависит от паралельности.
LogrusAS
Зато когда я начал использовать BulkInsert (а в OLEDB он не так уж прост как в NET) то вставка не выполнялась с сообщением о невозможности делать BulkInsert из сессии где проводятся другие операции! Хотя Connection создавался новый, но из того же udl файла.
Ну это просто баг в библиотеках доступа, а может и в коде... Получается, что были созданы 2 объекта Connection, но реально они использовали один коннект? Наверное, такое можно поймать и отладить...
23 янв 13, 17:55    [13817286]     Ответить | Цитировать Сообщить модератору
 Re: Многопоточность, Entity Framework и SQL  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31865
ProgED
Может кто-нибудь знает как заставить SQL-сервер обрабатывать несколько различных запросов одного приложения, но с несколькими потоками?
Собственно, SQL-сервер по другому не умеет, он не может обрабатывать команды от нескольких коннектов в одном потоке.
Просто отлаживайте приложение, очевидно, у вас используется один коннект, проблема либо в написанном коде, либо в настройках Entity Framework.
ProgED
Просто слышал что драйвер SQL при совпадении всех параметров строки подключения не создает новое соединение для клиента, а использует одно и то же...
Не, драйвер так не делает, и вообще при использовании апп-серверов обычно используют однгого пользователя, и всё нормально.
23 янв 13, 17:59    [13817323]     Ответить | Цитировать Сообщить модератору
 Re: Многопоточность, Entity Framework и SQL  [new]
Monochromatique
Member [заблокирован]

Откуда:
Сообщений: 1936
alexeyvg
очевидно, у вас используется один коннект,


Как в этом удостовериться??
24 янв 13, 14:06    [13821512]     Ответить | Цитировать Сообщить модератору
 Re: Многопоточность, Entity Framework и SQL  [new]
Ken@t
Member

Откуда: 大地
Сообщений: 3264
Monochromatique,
Профайлером посмотреть spid и включить трассировку login logout
24 янв 13, 14:42    [13821801]     Ответить | Цитировать Сообщить модератору
 Re: Многопоточность, Entity Framework и SQL  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31865
Monochromatique
alexeyvg
очевидно, у вас используется один коннект,


Как в этом удостовериться??
Да, профайлером.
Хочу уточнить:
ProgED
Может кто-нибудь знает как заставить SQL-сервер обрабатывать несколько различных запросов одного приложения, но с несколькими потоками?
SQL Server вообще ничего не знает о приложении - одно оно, их много и т.п.

Он просто принимает сетевые пакеты с запросами, обрабатывает их, и отсылает обратно результат. Так что это сама по себе формулировка неправильная.

Багов в средствах доступа тоже не может быть - раз вообще с одного компьютера можно создать несколько коннектов (пусть из разных программ, например, из SSMS), значит, баги тоже нет.

Остаётся бага в своём коде, либо бага в библиотеке работы с данными верхнего уровня, типа Entity Framework, либо неправильное применение этих библиотек.
Бага в Entity Framework тоже маловероятна - слишком распространённая библиотека, а бага слишком крупная.

Соответствено нужно профайлером посмотреть, что реально происходит, и дальше отлаживать по цепочке (может быть, написать прогу для отладки всяких настроек Entity Framework, и долго выполняемую процедуру/запрос, с задержкой внутри).
24 янв 13, 18:15    [13823474]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить