Альтернатива mysql_pconnect для драйвера mysqli в php 5.3

[Riateche]

А не проще в конфиге прописать hostname с префиксом? Или так не будет работать?

Разработчикам патч отправили?

[Zabatov]

Если прописать в конфиге, то не работает: «Unable to connect to your database server using the provided settings».

Надо поставить проверку на версию пыхи и отправить.

[Evengard]

Лучше так помом:
function db_pconnect(){
$oldName = $this->hostname;
$this->hostname = 'p:'.$this->hostname;
$this->db_connect();
$this->hostname = $oldName;
}

А вот зачем проверка на версию я не понимаю

[Zabatov]

Да, так действительно будет лучше, чтобы не повлиять на другие участки программы.
На php.net написано:

[Zabatov]

Случайно отправилось
На php.net написано: Persistent connection support was introduced in PHP 5.3 for the mysqli extension.

На деле я не проверял, но как вариант — возможно выпадение ошибки при работе с более ранними версиями.

[Evengard]

А, понятно. Действительно, префикс не распознает и попытается законнектиться в пустоту…

[Evengard]

Тогда если на то пошло надо делать парсинг на наличие уже p: в строке хостнейма. Как то вот так тогда:
function db_pconnect(){
$oldName = $this->hostname;
$ver=phpversion();
$verArray=explode(".", $ver);
$verInteger=10000*$verArray[0]+100*$verArray[1]+$verArray[2];
if(strpos($this->hostname, «p:»)!==0 && $verInteger>=50300)
{
$this->hostname = 'p:'.$this->hostname;
}
$this->db_connect();
$this->hostname = $oldName;
}

Дико извиняюсь за то, что не обрамляю в теги — карма ниже нуля всё равно не даёт это сделать…

[Opik]

Ужос, не лучше ли проверять версию пыхи, например, так:

if (version_compare(PHP_VERSION, '5.3.0') >= 0) {
{
echo 'I am at least PHP version 5.3.0, my version: '. PHP_VERSION. "\n";
}

[Evengard]

Не знал про version_compare. Вы конечно же правы.

[alexxz]

Ага, а в мане ДОЛЖНЫ БЫЛИ БОЛЬШИМИ БУКВАМИ написать, что велика вероятность того, что после включения persistent connection в PHP ваше приложение начнёт сильно сбоить. На эту тему на грядущем хайлоаде доклад как раз будет.

[Zabatov]

а можно подробнее?

[datacompboy]

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

[FractalizeR]

Кстати, feature request на SQL эквивалент висит сброса соединения висит аж с 2007.

[alexxz]

Если немного подробнее:
1) Вместе с коннекшеном передаётся его стейт, а именно: временные таблицы, открытые транзакции, переменные, кодировки, времнная зона и т.д.
2) Вместе с коннекшеном передаются ещё хендлеры запросов (то что было у сервера запрошено, но ещё не отфетчено) — тут вплоть до получения ответа от предыдущего запроса.
3) От каждого воркера бекнда будет один постоянный коннект к БД (10 бекэндов * 50 воркеров порождают 500 постоянных коннектов к БД).

[sylvio]

коннекшн, стейт, хэндлер, воркер, бекенд? вы это на каком языке написали?

[Zabatov]

так и что с этим делать? Если постоянно соединяться — не тру из-за затраты большого времени на соединение, а pconnect тянет за собой кучу всего? Все-таки предпочесть pconnect, но ооочень аккуратно?

[alexxz]

Использовать можно, но очень очень аккуратно, полностью понимая, чем рискуешь. А также стоит понимать, что выигрыш будет примерно на 5-10 пакетов то есть на 5-10 мс в лучшем случае.

Вобщем инструмент довольно опасный и использовать его надо очень ответственно.

[ddosia]

Извините за то что пишу в этот пост, хотя он уже не очень свежий, но хотелось бы перенять лучшие практики:

выигрыш будет примерно на 5-10 пакетов то есть на 5-10 мс в лучшем случае

это немного не верно.

• Основыне затраты соединения не в кол-ве переданных байт, собственно во времени его установления и закрытия. Например в линуксах время ожидания можно посмотреть в "/proc/sys/net/ipv4/tcp_fin_timeout", на федоре это 60с.
• Т.к. количество соединений с сервером c одного ip ограничено 65k, оно всё же может исчерпаться: 65535 соединений / 60 с ~ 1093 соед/секунду. Если у вас есть поля с автодополнением, которые дёргают данные из базы, то это не так уж и нереально.
• На каждое соединение тратятся соединения как сервера, так и клиента. А если клиент и сервер на одном физическом узле, то *2. Наверное тут нужен коммент от квалифицированного dba, который может сказать что-нибудь про пулы соединений со стороны бд.

про недостатки pconnect вполне ясно: это всякого рода пересечения разных запросов (данные одного, пришли в ответ другом, кстате как на счет того, что при продолжительном запросе, все последущие ждут его выполнения?)

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

[Kakysha]

А фреймворк то не указали :p
CI?

[hellohaos]

Пост находится в блоге фреймворка CodeIgniter…

[sdevalex]

mysql_* — зло и отголосок мусорности интернет… Эти функции вроде насильно отменили вроде?

[Zabatov]

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

mysql_ экстеншеном никто и не пользуется. Я привел как раз его альтернативу для mysqli. На mysql_ в CI pconnection прекрасно работает, а вот с mysqli проблема, видимо из-за совместимости со старыми версиями PHP решили просто перенаправлять запрос с pconnection на обычный или просто забыли реализовать, когда такая возможность появилась.

[Zabatov]

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