Даже и не знаю, сюда или в форум по БД...
Клиентское приложение подключается к MS SQL Server 2000 и что-то там делает.
Потом пользователь уходит пить чай на некоторое время (пускай будет от 10-15 минут и более).
После этого возвращается и хочет, например, посмотреть документ, хранящийся в БД. И вот тут начинаются тормоза при установлении соединения с БД — задержка может достигать 10 секунд, что очень неприятно
После открытия первого документа, работа продолжается без тормозов до того момента, пока пользователь не пойдет, например, охмурять секретаршу
И клиентское приложение и сервер работают под Windows 2000 (машины, естественно разные). Компы нормальные, ниже четвертого пня нет, сервак двухголовый и крутятся на нем тоько сиквель и терминал, нагрузка на сервак маленькая — пользователей всего 5-6 человек. Памяти на всех машинах более чем достаточно.
В чем может быть причина? Куда копать?

Здравствуйте, GuinPin, Вы писали:

GP>Потом пользователь уходит пить чай на некоторое время (пускай будет от 10-15 минут и более).
GP>После этого возвращается и хочет, например, посмотреть документ, хранящийся в БД. И вот тут начинаются тормоза при установлении соединения с БД — задержка может достигать 10 секунд, что очень неприятно
GP>После открытия первого документа, работа продолжается без тормозов до того момента, пока пользователь не пойдет, например, охмурять секретаршу
GP>И клиентское приложение и сервер работают под Windows 2000 (машины, естественно разные). Компы нормальные, ниже четвертого пня нет, сервак двухголовый и крутятся на нем тоько сиквель и терминал, нагрузка на сервак маленькая — пользователей всего 5-6 человек. Памяти на всех машинах более чем достаточно.
GP>В чем может быть причина? Куда копать?

Так все правильно. Честное соединение устанавливается долго, однако потом оно попадает в пул.

Здравствуйте, GuinPin, Вы писали:

GP>В чем может быть причина? Куда копать?

Посмотреть в строке подключения к БД наличие параметра Connection Lifetime.
PS Что за приложение, кстати? (обычная формочка или ServicedComponent используются)

Здравствуйте, AndrewVK, Вы писали:

AVK>Так все правильно. Честное соединение устанавливается долго, однако потом оно попадает в пул.

Слышал я про него краем глаза...
А настраивать параметры пула соединений можно?

Здравствуйте, GuinPin, Вы писали:

У Вас SqlServer пропаченый или нет? Если нет то тогда пропачте его (я ставил SP3)
Если нет SP то память утекает.

Здравствуйте, GuinPin, Вы писали:

GP>Слышал я про него краем глаза...
GP>А настраивать параметры пула соединений можно?

Можно. См. описание свойства SqlConnection.ConnectionString в MSDN

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, GuinPin, Вы писали:

GP>>В чем может быть причина? Куда копать?

А>Посмотреть в строке подключения к БД наличие параметра Connection Lifetime.

Этот параметр определит, сколько будет жить соединение в пуле после Connection.Close()?

А>PS Что за приложение, кстати? (обычная формочка или ServicedComponent используются)
Обычная форма.

Здравствуйте, GuinPin, Вы писали:

GP>Этот параметр определит, сколько будет жить соединение в пуле после Connection.Close()?

Если этот параметр не определять, то должно жить до закрытия приложения

10 секунд — это действительно много. Возможно что то с авторизацией. Я бы снифером посмотрел что между машинами происходит

>Потом пользователь уходит пить чай на некоторое время (пускай >будет от 10-15 минут и более).
Пул соединений, естественно, тут ни причем.
Говоря простым языком, дело вот в чем. Соединение после долгого ожидания переходит из режима (или статус) Runnable в режим Sleep. Поэтому при его активизации происходит некоторая подготовительная работа, что вы и можете наблюдать.
Что делать? Создать локальный кэш данных — например, использовать DataSet.

---

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Здравствуйте, Аноним, Вы писали:

>>Потом пользователь уходит пить чай на некоторое время (пускай >будет от 10-15 минут и более).
А>Пул соединений, естественно, тут ни причем.
А>Говоря простым языком, дело вот в чем. Соединение после долгого ожидания переходит из режима (или статус) Runnable в режим Sleep. Поэтому при его активизации происходит некоторая подготовительная работа, что вы и можете наблюдать.
А>Что делать? Создать локальный кэш данных — например, использовать DataSet.

Нет, это не решение проблемы. Во-первых, объемы данных растут быстро, поэтому тянуть в память копию БД радость не велика — уже сейчас приложение в памяти занимает 50-70 метров Во-вторых, у меня нет никаких гарантий, что данные в БД не были изменены, т.е. при использовании локального кэша придется разруливать и эту проблему.
В принципе, есть мысля использовать Remoting и организовать прослойку между БД и пользователем, своеобразный сервер приложений. Тогда действительно можно будет использовать один на всех датасет с данными документа, причем, если удаленный датасет будет работать аналогично локальному, есть шанс избавиться от проблемы нотификации клиентов для обновления локальных данных.
Правда, с ремоутингом я только начал разбираться, поэтому придется посмотреть, насколько такой вариант можно использовать...

Здравствуйте, Аноним, Вы писали:

А>Говоря простым языком, дело вот в чем. Соединение после долгого ожидания переходит из режима (или статус) Runnable в режим Sleep. Поэтому при его активизации происходит некоторая подготовительная работа, что вы и можете наблюдать.

Ничего подобного. Переход из Sleep в Runnable не может занимать 10 секунд.

PS
Runnable — SPID is currently executing.
Sleeping — SPID is not currently executing. This usually indicates that the SPID is awaiting a command from the application

Т.е. любой коннекшн который не исполняет в данный момент SQL-батч, находится в Sleeping состоянии (т.е. в Sleeping соединение не переходит "через некоторое время бездействия", а сразу же по завершению исполнения батча)