Comments 26
А не проще в конфиге прописать hostname с префиксом? Или так не будет работать?
Разработчикам патч отправили?
Разработчикам патч отправили?
Если прописать в конфиге, то не работает: «Unable to connect to your database server using the provided settings».
Надо поставить проверку на версию пыхи и отправить.
Надо поставить проверку на версию пыхи и отправить.
Лучше так помом:
function db_pconnect(){
$oldName = $this->hostname;
$this->hostname = 'p:'.$this->hostname;
$this->db_connect();
$this->hostname = $oldName;
}
А вот зачем проверка на версию я не понимаю
function db_pconnect(){
$oldName = $this->hostname;
$this->hostname = 'p:'.$this->hostname;
$this->db_connect();
$this->hostname = $oldName;
}
А вот зачем проверка на версию я не понимаю
Да, так действительно будет лучше, чтобы не повлиять на другие участки программы.
На php.net написано:
На php.net написано:
Случайно отправилось
На php.net написано: Persistent connection support was introduced in PHP 5.3 for the mysqli extension.
На деле я не проверял, но как вариант — возможно выпадение ошибки при работе с более ранними версиями.
На php.net написано: Persistent connection support was introduced in PHP 5.3 for the mysqli extension.
На деле я не проверял, но как вариант — возможно выпадение ошибки при работе с более ранними версиями.
А, понятно. Действительно, префикс не распознает и попытается законнектиться в пустоту…
Тогда если на то пошло надо делать парсинг на наличие уже 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;
}
Дико извиняюсь за то, что не обрамляю в теги — карма ниже нуля всё равно не даёт это сделать…
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;
}
Дико извиняюсь за то, что не обрамляю в теги — карма ниже нуля всё равно не даёт это сделать…
Ага, а в мане ДОЛЖНЫ БЫЛИ БОЛЬШИМИ БУКВАМИ написать, что велика вероятность того, что после включения persistent connection в PHP ваше приложение начнёт сильно сбоить. На эту тему на грядущем хайлоаде доклад как раз будет.
а можно подробнее?
ресет коннекшену делать надо.
иначе контекст от предыдущего сохраняться может, транзакции, прочие радости
иначе контекст от предыдущего сохраняться может, транзакции, прочие радости
Кстати, feature request на SQL эквивалент висит сброса соединения висит аж с 2007.
Если немного подробнее:
1) Вместе с коннекшеном передаётся его стейт, а именно: временные таблицы, открытые транзакции, переменные, кодировки, времнная зона и т.д.
2) Вместе с коннекшеном передаются ещё хендлеры запросов (то что было у сервера запрошено, но ещё не отфетчено) — тут вплоть до получения ответа от предыдущего запроса.
3) От каждого воркера бекнда будет один постоянный коннект к БД (10 бекэндов * 50 воркеров порождают 500 постоянных коннектов к БД).
1) Вместе с коннекшеном передаётся его стейт, а именно: временные таблицы, открытые транзакции, переменные, кодировки, времнная зона и т.д.
2) Вместе с коннекшеном передаются ещё хендлеры запросов (то что было у сервера запрошено, но ещё не отфетчено) — тут вплоть до получения ответа от предыдущего запроса.
3) От каждого воркера бекнда будет один постоянный коннект к БД (10 бекэндов * 50 воркеров порождают 500 постоянных коннектов к БД).
коннекшн, стейт, хэндлер, воркер, бекенд? вы это на каком языке написали?
так и что с этим делать? Если постоянно соединяться — не тру из-за затраты большого времени на соединение, а pconnect тянет за собой кучу всего? Все-таки предпочесть pconnect, но ооочень аккуратно?
Использовать можно, но очень очень аккуратно, полностью понимая, чем рискуешь. А также стоит понимать, что выигрыш будет примерно на 5-10 пакетов то есть на 5-10 мс в лучшем случае.
Вобщем инструмент довольно опасный и использовать его надо очень ответственно.
Вобщем инструмент довольно опасный и использовать его надо очень ответственно.
Извините за то что пишу в этот пост, хотя он уже не очень свежий, но хотелось бы перенять лучшие практики:
это немного не верно.
про недостатки pconnect вполне ясно: это всякого рода пересечения разных запросов (данные одного, пришли в ответ другом, кстате как на счет того, что при продолжительном запросе, все последущие ждут его выполнения?)
Хотелось бы понять, как взрослые дядьки с большой нагрузкой решают эту проблему.
выигрыш будет примерно на 5-10 пакетов то есть на 5-10 мс в лучшем случае
это немного не верно.
- Основыне затраты соединения не в кол-ве переданных байт, собственно во времени его установления и закрытия. Например в линуксах время ожидания можно посмотреть в "/proc/sys/net/ipv4/tcp_fin_timeout", на федоре это 60с.
- Т.к. количество соединений с сервером c одного ip ограничено 65k, оно всё же может исчерпаться: 65535 соединений / 60 с ~ 1093 соед/секунду. Если у вас есть поля с автодополнением, которые дёргают данные из базы, то это не так уж и нереально.
- На каждое соединение тратятся соединения как сервера, так и клиента. А если клиент и сервер на одном физическом узле, то *2. Наверное тут нужен коммент от квалифицированного dba, который может сказать что-нибудь про пулы соединений со стороны бд.
про недостатки pconnect вполне ясно: это всякого рода пересечения разных запросов (данные одного, пришли в ответ другом, кстате как на счет того, что при продолжительном запросе, все последущие ждут его выполнения?)
Хотелось бы понять, как взрослые дядьки с большой нагрузкой решают эту проблему.
А фреймворк то не указали :p
CI?
CI?
mysql_* — зло и отголосок мусорности интернет… Эти функции вроде насильно отменили вроде?
Привет, Барич )
По поводу грабель и pconnection могу сказать, что пришел к этому экспериментальным путем и о граблях pconnection'а не задумывался. До сегодняшнего дня не знал, что количество записей в бд как-то может быть связано со скоростью соединения с самой бд. Добавил в таблицу около миллиона записей и вуаля, 10 секунд только на соединение.
mysql_ экстеншеном никто и не пользуется. Я привел как раз его альтернативу для mysqli. На mysql_ в CI pconnection прекрасно работает, а вот с mysqli проблема, видимо из-за совместимости со старыми версиями PHP решили просто перенаправлять запрос с pconnection на обычный или просто забыли реализовать, когда такая возможность появилась.
По поводу грабель и pconnection могу сказать, что пришел к этому экспериментальным путем и о граблях pconnection'а не задумывался. До сегодняшнего дня не знал, что количество записей в бд как-то может быть связано со скоростью соединения с самой бд. Добавил в таблицу около миллиона записей и вуаля, 10 секунд только на соединение.
mysql_ экстеншеном никто и не пользуется. Я привел как раз его альтернативу для mysqli. На mysql_ в CI pconnection прекрасно работает, а вот с mysqli проблема, видимо из-за совместимости со старыми версиями PHP решили просто перенаправлять запрос с pconnection на обычный или просто забыли реализовать, когда такая возможность появилась.
Sign up to leave a comment.
Альтернатива mysql_pconnect для драйвера mysqli в php 5.3