как коректно подключиться / отключиться от базы?

[dusya]

Автор оригинала: alexhemp
Если они на один хост с одним логином-паролем (99% нормальных скриптов и всяческих форумов-CMS). То следующее выполнение скрипта заюзает это-же соединение.

именно об этом я спрашивал. я несколько раз натыкался на
использование p_connect() оупенсорс скриптах (форумах,блогах,cms'ах).
это и побудило мое любопытсво

в большенстве случаев на каждый сайт приходиться по 1 базе и соотвествено по 1 пользователю mysql .

верно ли предполагать, что маскимальное количество открытых соединений к mysql посредством p_connect() равно количеству пользователей mysql ?

 

[Profic]

dusya
прочитай еще раз мой пост про чайлды апача. если не поймешь с первого раза перечитывай до просветления.

 

[dusya]

Profic
к сожелению оно ненастает...

неудомеваю, почему ж тогда во многих опенсорсах использують именно пи_коннект() ?

 

[tony2001]

по поводу "пулов":
при pconnect() в общем случае всё выглядит так:
кол-во открытых коннектов == равно кол-ву чайлдов Апача.
никаких "пулов" и "пометок" нет.
функцию попросили найти уже готовое соединение в списке или открыть новое - она именно это и делает.
сколько там уже его используют - функции все равно, они друг другу никак не мешают, это дело пользователя.

по поводу "too many..":
это проблема недостатка квалифицированных администраторов.
дефолтовое максимальное кол-во коннектов к MySQL меньше, чем то кол-во чайлдов, которое позволяют "рожать" апачу.
поскольку администраторы не подозревают, что это кол-во можно изменить в настройках MySQL, они рождают мифы о "глюках" и "плохости pconnect".
к сожалению, уже это само по себе создает проблемы.

по поводу "зачем":
в случае с MySQL pconnect() помогает сэкономить некие миллисекунды, которые тратятся на установку соединения.
на действительно загруженных сайтах это может чем-то помочь.
однако, коннект к MySQL устанавливается _действительно_ быстро (в отличие от Оракла, *sigh*..) и обычно такая экономия не является необходимой, т.к. я себе слабо представляю случай, где коннект к MySQL был бы пресловутым "узким местом".

по поводу "ничего не понял, объясните коротко":
юзайте connect(). оптимизируйте код и запросы.

 

[neko]

время подключения к mysql на некоторой машине примерно равно 0.01 - 0.005 cек.
это в 2 раза быстрее чем к mssql
в 5 раз быстрее чем к interbase
в 7 раз быстрее чем к firebird
и, наконец, в 9 раз быстре чем к postgre

на тех задачах, которые у вас могут возникнуть
для mysql не имеет абсолютно, совершенно никакого, смысла использовать pconnect

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

 

[camka]

Автор оригинала: tony2001
по поводу "пулов":
при pconnect() в общем случае всё выглядит так:
кол-во открытых коннектов == равно кол-ву чайлдов Апача.
никаких "пулов" и "пометок" нет.
функцию попросили найти уже готовое соединение в списке или открыть новое - она именно это и делает.
сколько там уже его используют - функции все равно, они друг другу никак не мешают, это дело пользователя.

Значит ли это, что на один апаче чайлд не может быть больше одного коннекта к базе? То есть все паралельные скрипты, выполняющиеся на одном чайлде будут использовать один и тот же коннект (connection id) одновременно? И как следствие, если я, скажем, использую создаю/удаляю в скрипте временные таблицы, то возможно появление конфликтов в одновременно исполняемых скриптах?

 

[neko]

непонял какие параллельные скрипты на одном чайде???

 

[camka]

не знаю. я вот думал, что такое возможно. а что тогда ограничивает директива ThreadsPerChild апача ? количество запросов в очереди к одному чайлду?

А вообще, почитал комментарии к mysql_pconnect там вот тоже такая проблема встает

Be very careful when using persistent connections and temporary tables on MySQL: in MySQL, temporary tables are visible only to the currenct connection, but if you have a persistent connection the temporary tables will supposedly be visible to everybody sharing the same persistent connection. This can lead to major trouble. I suggest to use totally random temporary table names when using persistent connections to avoid major problems.

bartek at bulzak dot com
27-Feb-2002 12:37
PHP 4.1.1 running with Apache under Linux doesn't seem to be doing all necessary flushing when handling persistant mysql connections. Try it out for yourself. Create a temporary table in a pconnect session, add rows (non unique), select/display and drop the table. Now reload your script multiple times, you will see that your results are not consistent, even though you are creating a new table everytime and dropping it..

I had my share of problems with pconnect and suggest you don't use it unless absolutely necessary. In that case make sure you test your results for consistency, especially when your queries involve temporary tables or mysql session variables.

Bartek Bulzak

-~{}~ 12.12.04 00:22:

#
# Number of concurrent threads (i.e., requests) the server will allow.
# Set this value according to the responsiveness of the server (more
# requests active at once means they're all handled more slowly) and
# the amount of system resources you'll allow the server to consume.
#
ThreadsPerChild 50

 

[neko]

не знаю. я вот думал, что такое возможно. а что тогда ограничивает директива MaxRequestsPerChild апача ?

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

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

вообще, еще раз
для mysql пконнект -- это лишнее совершенно

 

[camka]

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

 

[neko]

да
об этом (сюрприз!) написано в мануале

 

[camka]

я сначала не поверил мануалу. но тебе верю. спасибо. я получил ответ на свой вопрос. если я убиваю временную таблицу в скриптах, то проблем возникнуть не должно. Причем убивать таблицу желательно не в конце скрипта, а непосредственно перед созданием этой самой временной таблицы, ну естественно с проверкой if exists, а иначе при сбое в середине скрипта таблица останеца висеть и может создать проблемы впоследствие.

 

[dusya]

Автор оригинала: tony2001
случай, где коннект к MySQL был бы пресловутым "узким местом".

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

в целом немного стало яснее что к чему, но возникает опять вопрос:
зачеж же mysql_close() , если после исполнения скрипта - ресурс освобождаеться ?

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

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

как посмотреть, сколько максимально коннектов может обслужить майскл?

 

[Profic]

tony2001

при pconnect() в общем случае всё выглядит так:
кол-во открытых коннектов == равно кол-ву чайлдов Апача

а как насчет вот этого?

hashed_details_length = sizeof("mysql___")-1 + strlen(SAFE_STRING(host_and_port))+strlen(SAFE_STRING(user))+strlen(SAFE_STRING(passwd)); hashed_details = (char *) emalloc(hashed_details_length+1); sprintf(hashed_details, "mysql_%s_%s_%s", SAFE_STRING(host_and_port), SAFE_STRING(user), SAFE_STRING(passwd));
...
if (zend_hash_find(&EG(persistent_list), hashed_details, hashed_details_length+1, (void **) &le)==FAILURE) { /* we don't */ 
    ...
    if (zend_hash_update(&EG(persistent_list), hashed_details, hashed_details_length+1, (void *) &new_le, sizeof(list_entry), NULL)==FAILURE) {
        ...
    }
    ...
} else {
    ...
}

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

 

[Admiral]

Originally posted by Фанат
icechel
а хз.
не буду строить из себя идиота, пытаясь выдумать.
может, найдется кто покомпетентнее.

К тебе большая просьбюа не писать на тему, в которой ты не смыслишь ни бельмеса =))

зы: ща наверно начнется членомерство, как это обычно бывает Ж)))