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

[ERrorMAKros]

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

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

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

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

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

[mikhailk]

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

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

[ERrorMAKros]

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

[StasSuper574]

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

[ERrorMAKros]

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

[mikhailk]

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

[ERrorMAKros]

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

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

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

Машина для  тестирования: intel сервер с 16Гб памяти, 2 процессора 
по 4 ядра (E8400), Linux CentOs 5.3 работающий как виртуальная машина. 
Сервер базы данных для тестирования
- FirebirdCS-2.1.2.18118-0.i686.rpm
- FirebirdCS-2.1.2.18118-0.amd64.rpm
- FirebirdSS-2.1.2.18118-0.i686.rpm

Clasic server:
максимальное количество коннектов в такой конфигурации ~850, после этого 
сервер отказывает в новых соединениях, общее количество процессов ~1000, 
для обычной и 64 разрядной версии.

Super server:
Казалось бы SS меньше зависит от настроек системы, но на практике получили
наоборот, после 288-го соединения получаем сообщение:
Unable to complete network request to host "85.x.x.x".
-Error writing data to the connection.
-Broken pipe
и все соединения, которые были установлены до 288 завершаются. Какие здесь
настройки править - тайна. Да и администрировать под Linux сервер SS сложно.
Хотя тормоза уже начинаются после 50 одновременно выполняемых sql, а после 100 
паузы в работе становятся огромными, я не смог достигнуть максимума в 1200 sql-ей. 

Вот тут сразу захотелось отказаться от своей реализации.

[mikhailk]

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

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

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

[ERrorMAKros]

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`ку) который будет отображать этот вид контента.

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

[mikhailk]

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

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

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

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

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


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