Я просел инструкции. Мне кажется- он лучше, чем mysql_connet().
Хочу выслушать мнения всевышних сайта сего

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

_____________
HTML, CSS (Bootstrap), JS(JQuery, ExtJS), PHP, MySQL, MSSql, Posgres, (TSql, BI OLAP, MDX), Mongo, Git, SVN, CodeIgnater, Symfony, Yii 2, JiRA, Redmine, Bitbucket, Composer, Rabbit MQ, Amazon (SQS, S3, Transcribe), Docker

Игорь_Vasinsky
ну, если у меня большая посещаемость сайта, и сам сайт на websockets-технологии- имхо- норм!

или на аяксе с дофига коннектов)

Почитай про лимит на количество открытых соединений в mysql.

_____________
Обучаю веб-программированию качественно и не дорого: http://school-php.com
Фрилансер, принимаю заказы: PHP, JS, AS (видео-чаты). Писать в ЛС (Личные сообщения на phpforum).

inpost
О_О сейчас гляну

500-100 коннектов.
Но можно и больше ставить, ведь!

Лучше юзать mysql_connect, при использовании постоянного соединения можно получить нагромождение незакрытых коннектов, открытых в разных процессах

Zzepish
Ты подумай, почему такой маленький лимит стоит? Или давай иначе, почитай, что значит маленькое количество открытых соединений и почему именно этот вариант является стандартом, если учесть, что большинство сайтов и являются лицом стандарта.
Представь себе 10 касс, в каждой кассе по 3 человека в очереди. Вроде нормально идёт процесс. Или же 100 касс на 30 человек, лишние ресурсы? Или 3 кассы на 30 человек, уже большая очередь... тут важен баланс.

_____________
Обучаю веб-программированию качественно и не дорого: http://school-php.com
Фрилансер, принимаю заказы: PHP, JS, AS (видео-чаты). Писать в ЛС (Личные сообщения на phpforum).

inpost
то есть, по сути, тут вообще надо подбирать идеальный вариант, расчитывая на дрессуры своего пк?

http://www.youtube.com/watch?v=7N3Ro4fa-30...ture=plpp_video

Аверин Сергей. Руководитель отдела десктопных приложений компании Badoo.
Участовал в создании проектов habrahabr.ru, dirty.ru, leprosorium.ru, autokadabra.ru, dribbler.ru, trendclub.ru.
DevConf 2012

На своей практике мы убедились, что с проблемами постоянных соединений типичные php-разработчики знакомы плохо. Чаще всего они полагаются на «авось», который перестает работать при первой серьезной нагрузке.

В докладе рассматриваются характерные проблемы, возникающие при использовании постоянных соединений. Рассматриваются проблемы, связанные с принципами работы ОС, построением stateful/stateless протоколов, особенностями сетевого взаимодействия по TCP, «грабли» и нюансы реализации постоянных соединений в php (рассмотрено несколько стандартных extension'ов и особенности FastCGI-режима).

Подробно:
На своей практике мы убедились, что с проблемами постоянных соединений типичные php-разработчики знакомы плохо. Чаще всего они полагаются на «авось», который перестает работать при первой серьезной нагрузке.

В докладе рассматриваются характерные проблемы, возникающие при использовании постоянных соединений. Рассматриваются проблемы, связанные с принципами работы ОС, построением stateful/stateless протоколов, особенностями сетевого взаимодействия по TCP, «грабли» и нюансы реализации постоянных соединений в php (рассмотрено несколько стандартных extension'ов и особенности FastCGI-режима).

Приведен обзор распространенных протоколов из мира веб (MySQL, Memcached, MongoDB и т. д.) и разобраны из плюсы и минусы.

Показаны пути решения на примере конкретного большого highload проекта и «граблей», на которые мы в нем наступали.
Показано несколько разносторонних путей организации работы с C/C++ софтом чере pconnect.
Описаны дополнительные ускоряющие работу и увеличивающие надежность подходы.
Рассмотрен connection pooling софт и приведен список рекоммендаций по проектированию архитектуры веб-приложений.