Подключение к базе данных в php
 

Добрый день, вот такой вот вопрос: существует php приложение в котором реализовано частое обращение к базе данных (mySQL, Firebird, Oracle). Вопрос вот в чем - при загрузке и работе проекта на сервере как лучше поступить:
1. Открыть один дескриптор (подключение) к БД и отправлять через него все SQL запросы на протяжении всего времени сессии пользователя;
2. Открывать и закрывать подключение к БД при каждом выполнении любого SQL запроса?

Помнится мне, что в Delphi подключение к базе выполняется один раз (при запуске программы) но это пример клиентского приложения, ..хотелось бы знать - как эта задача правильно решается в серверных приложениях!

Благодарю за внимание!

Немного уточню:
В моем случае php сервер участвует в проекте в роли интерфейса между flash на стороне клиента и БД на стороне сервера. Сессия в моем случае необходима только для проверок активности пользователя на странице (session_id() дает понять что клиент активен). Php отдает на сторону клиента данные привязанные к пользовательскому session_id(). Я наверное немного не правильно поставил вопрос, вот это наверное будет более правильная формулировка: насколько (приблизительно) сильна будет нагрузка на БД сервер, если PHP при каждом выполнении SQL запроса сначала будет:
1. Авторизироваться с БД;
2. Выполнять запрос;
3. Закрывать соединение с БД после выполнения запроса;
> Является ли такой метод корректным?

Или более правильная реализация будет - создание только одного подключения PHP к БД и отправлять/принимать через него результаты SQL запросов на протяжении всей активной работы сессии?

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

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

Я подумываю вот что - 100 подключений из 100 пользователей будет в любом случае. Ссылку на базу (точнее это object класс возвращающий Resource на базу (соответственно - с destructor`ом)) привязываю к сессии! Т.е. коннект к базе делается только один раз, во время запуска сессии и активна во все время активности сессии. Может все же лучше выполнять sql запросы через одно постоянное подключение, чем многоразовое подключение при каждом sql запросе? ...вот как бы это меня волнует.

А мужики-то не знают :)

...ну, не знают так не знают :) У меня эта реализация уже работает, вроде пока не жалуюсь. Но вот жду ситуации что бы посмотреть что будет когда к одному подключению обратятся два разных sql query запроса... или выполнятся поочередно, или будет crash.

два запроса в рамках одного соединения встанут в очередь и выполнятся.
краша тут вообще не видно
просто какой-то очередной пользователь при открытии приложения вместо соединения к базе получит false.
это если общее количество соединений будет превышено.

Re: два запроса в рамках одного соединения встанут в очередь и выполнятся.
краша тут вообще не видно Это обнадежило!

Re: просто какой-то очередной пользователь при открытии приложения вместо соединения к базе получит false.
это если общее количество соединений будет превышено.
А вот тут хотелось бы знать по подробней! Это как то фиксировано в php сервере (я подключаюсь к Firebird базе данных (ibase_connect))? Или кол-во соединений фиксирует сама database? ....ну как бы хочется понять о каких именно соединениях идет речь!

Если речь идет о БД, то вот результат некоторых тестов:
Вот тут сразу захотелось отказаться от своей реализации.

ERrorMAKros, :)
Вы идете по пути, по которому прошли уже сотни и тысячи программеров. Для самого среднего приложения в соцсети со среднесуточной посещаемостью около 20 тыс., в онлайне всегда будет в среднем 700 пользователей, а в отдельные моменты в пике и 1000. Продвинутые приложения имеют и 800 тыс. пользователей в сутки, т.е., в онлайне может быть 30-40 тысяч.

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

Логика построения таких серверов в принципе другая. С клиентом взаимодействует сервер приложения (пул серверов), который берет на себя всю нагрузку и держит у себя в кэше всю основную игровую информацию. А уже этот сервер приложения в свою очередь обращается к серверу БД. При этом количество запросов "клиент->сервер приложения" несопоставимо больше, чем "сервер приложения->сервер БД".

mikhailk, вы не представляете как вы кстате с вашим опытом, потому как ...я еще к этому всему ползу. Хочу чуть чуть рассказать - специфика моего приложения не является дополнением к соц. сети, мое приложение и является - соц. сетью (вот захотелось мне такое написать).
1. Firebird SQL database - хранит настройки GUI объектов и контент (она же определяет права доступа к контенту (в основном все на хранимых процедурах, таблиц совсем не много) + языковые пакеты для multilang реализации);
2. PHP - интерфейс между БД и клиентом;
3. Клиент - GUI Flash .swf оболочка, загружающая .swf объекты для управления контентом, окошки, менюшки и т.п. (это работает так:
клиент -> запрашивает объект у базы
база -> определяет где находится физическое тело (.swf) и имеет ли пользователь права доступа к нему,
php -> отправляет тело клиенту;
клиент -> обрабатывает .swf и уже этот самый .swf при успешной загрузке у клиента - загружает из БД (опять через php) языковой пакет и свои настройки) ...так же он может вызывать и другой объект или контент.

В целом это все будет представлять из себя информационную систему, картинки, заметки, mp3 проигрывание музыки. Физически сам контент разбросан по разным интернет адресам, БД хранит в себе только ссылки на них и отдает их Flash`у в случае если удовлетворяются права доступа. Flash обрабатывает и отображает контент в том виде в котором нужно (.jpg в картинки, .flv в видео и т.д.). На основе типа контента Flash обращается на сервер и получает объект (.swf`ку) который будет отображать этот вид контента.

До этого момента для меня моя разработка была ясна как день, пока вы не дали мне понять что ...у меня очень слабая работа с БД :( Подскажите где можно прочитать о том, как правильно построить соц. сеть или, что еще лучше, буду признателен если вы поделитесь опытом и парой советов по организации архитектуры БД в моем случа, потому как похоже что я вам в этом плане доверяю!

Ну, к социальным сетям я отношения не имею, могу лишь поделиться тем, как сделано сейчас у меня.

Сервер приложения написан на PHP, для хранения кэша приложения применяется MemCache. В кэше хранится информация, готовая к отдаче клиенту без какой-либо обработки.

В момент, когда от клиента идет запрос, скрипт php проверяет актуальную информацию в кэше и, если она есть, тут же ее отдает. Если ее нет, он лезет в базу, производит необходимую обработку и отдает, параллельно записывая в кэш. Когда клиент вносит изменения в базу, соответствующие данные в кэше должны быть сброшены. Тогда они при следующем запросе автоматически вычислятся заново и будут записаны в кэш.

Собственно, это все.

Основная сложность - обеспечение актуальности данных в кэше. Ошибки программирования, когда какие данные изменены в базе, но не сброшены в кэше, приводят к нарушению целостности информации и глюкам приложения. Иногда забавным, иногда не очень.


P.S. А вообще-то Вы взялись за достаточно серьезную разработку. Вы в курсе? :)