Организация пула соединений

← →
Ega23 © (2008-06-18 10:41) [0]

Ну вот и я дошёл наконец-то до многозвенки и, похоже, требуется сей зверь писать. Кто занимался (читал, видел, слышал) чем-то похожим - посоветуйте, что почитать на эту тему?
Сама задача для меня крайне интересная, но как и с какого боку к ней подступиться - пока не ясно. Сижу, гуглю.
В общем, буду признателен за любые наводки по этому вопросу, а за толковую статью - даже пиво проставлю. :)

← →
Palladin © (2008-06-18 10:51) [1]

Для создания многозвенного ПП предпосылки нужны. Оно, понимашь, понятие широченное. Создание и начинается с этих самых препосылок. Общего рецепта нет. Но существует куча технологий, начиная от простого специализированного сервера заканчивая SOAP и вебсервисами...

← →
Palladin © (2008-06-18 10:52) [2]

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

← →
DrPass © (2008-06-18 10:58) [3]

> Кто занимался (читал, видел, слышал) чем-то похожим - посоветуйте,
> что почитать на эту тему?

А что там читать? Сел в кресле, подумал и написал. Пул соединений - это просто массив этих самый соединений с функциями "запросить соединение" "отдать соединение". Как правило, потокобезопасный и, вероятно, со сборщиком мусора

← →
Поросенок Винни-Пух © (2008-06-18 10:59) [4]

зачем пул?
один клиент - один коннект к данным

← →
Ega23 © (2008-06-18 11:07) [5]

> один клиент - один коннект к данным
>

А когда 1000 клиентов? 1000 коннектов?

← →
Поросенок Винни-Пух © (2008-06-18 11:09) [6]

прям так сразу и тысяча.
в один момент.

← →
Ega23 © (2008-06-18 11:10) [7]

> прям так сразу и тысяча.
> в один момент.

Ну по прикидкам тысяча - аккурат средняя нагрузка. Пиковая - 2000.

← →
Romkin © (2008-06-18 11:10) [8]

Обычно да :)
Пул соединений применяется обычно для stateless клиентов, которые присоединяются к серверу, берут данные и сразу отключаются. Потом снова. Коннект обычно долгий (инициализация объектов, соединение с БД и тд), поэтому держат соединения про запас.
Но если есть возможность держать соединение постоянно - почему нет?

← →
Поросенок Винни-Пух © (2008-06-18 11:12) [9]

если будет пул на сто коннектов для тысячи клиентов это примерно равносильно ограничению числа коннектов к фронту.
пока в пуле не освободится сессия с данными сто первый клиент курит

← →
Поросенок Винни-Пух © (2008-06-18 11:15) [10]

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

← →
Ega23 © (2008-06-18 11:21) [11]

> если будет пул на сто коннектов для тысячи клиентов это
> примерно равносильно ограничению числа коннектов к фронту.
>
> пока в пуле не освободится сессия с данными сто первый клиент
> курит

Сессий - 1000. Но это не значит, что они все разом данные тянут.

← →
Поросенок Винни-Пух © (2008-06-18 11:22) [12]

не так чтобы авторизоваться сто первому нежен свободный коннект к бд
откуда там тысяче сессий взятся?

← →
Ega23 © (2008-06-18 11:29) [13]

> не так чтобы авторизоваться сто первому нежен свободный
> коннект к бд

Ну и нормально. Есть свободный - взял его, попользовался и отдал. Нет - ну либо подождал, либо создал новый.

Меня больше тут потоки и потокозащищённость интересуют, т.к. с этим делом толком не работал.

← →
Поросенок Винни-Пух © (2008-06-18 11:29) [14]

в общем если хочется именно пул, то можно и пул.
как сделано у меня:
-пришел клиент, я определил, что он "новый"
-создаю ему модуль данных для коннекта с бд, и отдаю сгенеренный "куки" (guid)
- выполняю чо он хочет, отдаю данные, закрываю http сессию
- через минуту приходит он же ("с кукой").
- ищу его модуль данных и если его уже нет, создаю новый и прошу авторизоваться.
- если модуль еще жив, просто выполняю запрос и отдаю данные.

то есть коннекты к бд независимы, хоть и логически привязаны к клиенту.
если привязки не делать, получится тот же самый пул.
нужно только все время махать флагами занятости/свободности модуля данных.

← →
DrPass © (2008-06-18 11:32) [15]

> Поросенок Винни-Пух © (18.06.08 11:12) [9]
> если будет пул на сто коннектов для тысячи клиентов это
> примерно равносильно ограничению числа коннектов к фронту.
>

Для того пул и делается - чтобы разумно распределять нагрузку на СУБД

← →
Поросенок Винни-Пух © (2008-06-18 11:34) [16]

Для того пул и делается - чтобы разумно распределять нагрузку на СУБД

так я и говорю, ограничить число сессий с сервером приложений - будет тоже самое.

← →
Ega23 © (2008-06-18 11:35) [17]

> так я и говорю, ограничить число сессий с сервером приложений
> - будет тоже самое.
>

А вот этого уже быть не должно. Ибо СП кроме коннекта с БД ещё массу всякого разного делает.

← →
Поросенок Винни-Пух © (2008-06-18 11:37) [18]

Удалено модератором

← →
KSergey © (2008-06-18 11:41) [19]

> Поросенок Винни-Пух © (18.06.08 11:29) [14]
> как сделано у меня:

В схеме не описано когда исчезает модуль данных. Можно уточнить?

И еще. Получается, что кол-во коннектов к БД всегда равно кол-ву "активных" пользователей (активный он до тех пор, по сути, пока его не попросили заново регистрироваться). Это я правильно понял?

← →
Ega23 © (2008-06-18 11:43) [20]

А, я понял о чём ты.
Сервер в базу ходит под одной и той же учёткой, авторизация пользователя происходит на СП, а не на сервере БД.

Модули данных умирают по завершению таймаута (клиент ассоциированный с модулем ничего не делал в течение X минут)

Число коннектов всегда не меньше количества активных пользователей.
У клиента трансортом http с Connection : Close

Сервер в базу ходит под одной и той же учёткой

Да. Просто клиенты это не инсайдеры. Для них нет никаких учетных записей в AD предприятия.

> Поросенок Винни-Пух © (18.06.08 11:44) [21]
> Число коннектов всегда не меньше количества активных пользователей.

Коннектов к БД, верно?
Мдя, дороговастенько.... Хотя, конечно, от задач и потребностей зависит.

зависит от приоритетов.
кто-то сервер бережет чтобы не устал, кто-то считает, что задержка в обслуживании это недопустимо.

> Ega23 [1]

Тут всё просто.

Предположим, у нас есть СУБД, сервер приложений (СП) и клиент, причём СУБД и СП общаются по OleDB/ADO/ADO.NET, а способ общения СП и клиента изучим ниже.

Итак, если мы используем OleDB драйвер (a ADO - это всего лишь тонкая надстройка над OLE DB), то поддержка Connection Pooling в свежих версиях драйверов реализована почти для всех СУБД, а включение этой фичи задаётся соотв. параметром строки соединения (см. MSDN, например http://msdn.microsoft.com/en-us/library/ms254502.aspx). Парадигма использования соединений такова: открыть соединение, выполнить запрос, и как можно быстрее закрыть. После закрытия соединение автоматически возвращается в пул:

Set pConn = CreateObject("ADODB.Connection") pConnConnectionString = "..." pConn.Open Set pRs = pConn.Execute("select * from test") pConn.Close

Далее. От имени какой учётной записи работать с базой? Обычно, действительно, СП настраивают таким образом, что он работает с БД от имени одной-единственной учётной записи, поскольку в том случае, если с одной машины к СУБД будет установлено два подключения, у которых будут отличаться строки соединения, то будет задействован дополнительный физический ресурс (TCP-соединение, PIPE и др.), что увеличивает нагрузку на сервер. При таком подходе несколько сложнее рулить привилегиями, поэтому в данной архитектуре функции аутентификации и авторизации обычно выносят на сервер приложений.

Ну и наконец, как наладить общение клиента и СП? Тут вариантов море, и сейчас модно использовать архитектуру SOA: на СП разворачивается пул сервисов (веб-сервисов, WCF-сервисов, Remoting-сервисов, COM+-сервисов), которые выдают по запросу клиента некий пакет данных (XML/SOAP-документ, сериализованный граф объектов (Data Transfer Objects) и т.д.) и забывают о нём. Клиент работает с полученным пакетом, делает в нём изменения и шлёт изменённый пакет на сервер приложений сервису. Сервис распознает изменения и выполняет обновления в базе данных. Вот и всё.

В MSDN куча информации по архитектуре многозвенок.

> что почитать на эту тему?

1) "Design Considerations for MIDAS/DataSnap" by Vino Rodrigues

2) "A Technical View of Borland MIDAS" 1997 by Charlie Calvert
http://info.borland.com/midas/papers/

3) http://dn.codegear.com/delphi/distcomp/midas

4) "MIDAS. Практическое применение" Роман Игнатьев RSDN Magazine #2

Многозвенка - не обязательно MIDAS.

4. http://rsdn.ru/article/db/midas.xml

Организация пула соединений Найти похожие ветки