15 ноября 2009 в 3:21
Пул соединений с БД может немного облегчить нагрузку на сервер для посещаемых ресурсов.
Drupal в includes/database.mysql.inc использует mysql_connect который нельзя просто так поменять на mysql_pconnect по простой причине:
Вы получите кучу соединений с блокировками таблиц(через LOCK TABLES) и временными таблицами, висящими до истечения таймаута.
Однако проблема решается, если переписать драйвер mysql для друпала учитывая это.
Файлик во вложении. При его работе не будет создаваться новое соединение с базой если оно уже есть, что может несколько ускорить работу сайта.
PS: админам. замените наконец JS загрузки файлов на тот который верно с оперой работает.
| Вложение | Размер |
|---|---|
 database.mysql_.inc-persistent.txt | 11.88 КБ |
Комментарии
Ильяс может патч?
и переполнения не будет?
переполнения чего? осноные 2 проблемы дру - временные таблицы и локи. там они отслеживются и убиваются.
коннектов.
нет - их число ограничено. + есть таймаут у каждого коннекта. по неактивности они умирают.
в mysqli проблему подчистки и поддержки персистентов при дисконнекте решили в php 5.3. а тут приходится пользовать убогий mysql.so
в виде патча:
А почему не предложить сие в ядро? в 7ку еще вполне можно засунуть, там правда все совсем по другому, есть например поддержка нескольких подключений.
ну а в 6ку в виде фикса, имхо, тоже вполне можно - если объединить усилия и убедить Габра.
потому что это частный случай. и по хорошему для таких фокусов для дру надо отдельным драйвером такую шнягу делать. так корректнее.
ненене девидблейн. это дл дедиков и VPS. для шаредов не катит.
как вариант - свой драйвер базы для дру. считай свой файл инклуда.
Имхо проще сделать дополнительный параметр в settings.php и анализировать его в дравере, а в 7ке вообще можно из контриба такое делать
ЗЫЖ Илья, почему ты не пользуешься патчами? Как по-твоему втыкать в то, что ты сделал?
diff сделать и ффтыкать. этот инклуд не особо меняется от релиза к релизу.
анализ производительности есть?
нема. на глазок шустрее. ну и на своей шкуре ab потестил. 3-5% - но у меня и на сайте мало че есть.
У клиента мускуль с памятью интенсивно крутит - походу чуток запросы шустрей пошли.поприятнее - на нагруженном проце mysql_connect начинает время жрать на себя больше. я делал для частного случая.
Спасибо!
Как раз вчера вкуривал http://phplens.com/lens/php-book/optimizing-debugging-php.php
Очень хорошая и подробная статья, рекомендую к прочтению
так вот там, в разделе "Overload on 40 connections" как раз говориться, что "persistent database connections" могут породить множество проблем в работе сайта, при определенных условиях.
да. при условиях что пацаны не могут настроить mysql под нагрузку. судя по тому что в статье одна вода так оно и есть.
mysql популярен, в частности, из-за нежелания/неумения пацанов заниматься тюнингом сервера БД.
и именно поэтому mysql, а не postgresql, дефолтная бд в друпале. )
Ну это Вы зря. Я там много чего интересного и нового почерпнул.
Это Вы то же зря. Эти "пацаны" только и занимаются "настройкой под нагрузку" и у них это видимо хорошо получается.
А еще советую задуматься почему "persistent database connections" не в ядре.
Вы думаете мы тут все самые умные сидим?
потому что не реализовали
Хм... Не реализовали до семерки? Странно, особенно в свете того, что в данный момент Дрис особенно озабочен тормозами D7 (открою вам секрет, D7 тормознее чем D6+CCK).
В любом случае, я не хочу с Вами спорить, я Вас очень уважаю как программиста.
Однако мир может быть намного сложнее чем кажется. Вот и все, что я имел ввиду.
Может быть Вы правы, а может быть не совсем. Тут нужно еще разбираться.
ну не надо было ну и не сделали. проблема с этими коннектами лишь в одном - закончил работу - подчисти данные.
в php 5.3 драйвер mysqli делает это автоматом. Не будет подчистки будет butthurt с коннектами - кончатся буфера у mysql и он все будет скидывать на винт. пойдут тормоза.
Я всего лишь добавил эту подчистку. в 6ой версии в известных мне модулях кроме локов таблиц и временных таблиц дру ничего такого не делает требуещего заносить за ним хвосты еще. (насколько я знаю. мало ли какие еще есть модулеписатели - у mysql есть и другие типы блокировок )
Как-то не встречался я в 6ке со временными таблицами, так что аргументы не о чем...
Скорее причина в невостребованости сего... особенно учитывая что проекты расчитанные на производительность работают на pressflow с кешами и master-slave базами, так что там врят ли вообще стоит вопрос о количестве соединений...
http://api.drupal.org/api/function/db_query_temporary/6
в модулях сторонних используется. надо подчищать
ооо, эту версию днем с огнем не найдешь..
айайайай. оффтопик. какой стыд.
На.
http://brainstorm.name/misc/jquery.form.js
Вообще патч многократно выкладывался на форумах jquery и в CVS/SVN
Вы просто плохо искали.
А в /misc не пойдет?
Если же используется mysqli, то замена
<?php $connection = mysqli_init();@mysqli_real_connect($connection, $url['host'], $url['user'], $url['pass'], substr($url['path'], 1), $url['port'], NULL, MYSQLI_CLIENT_FOUND_ROWS);
?>
на
<?php$connection = mysqli_connect('p:'.$url['host'], $url['user'], $url['pass'], substr($url['path'], 1));
?>
достаточна?
К сожалению, не нашел функции для установки флага MYSQLI_CLIENT_FOUND_ROWS, обязателен ли он?
Лучше б АПИ читал.
Нафига ты себе забиваешь моск раньше времени? Вот когда около ~100 000 просмотров будет на серванте, тогда и будешь думать про постоянные конекты
АПИ читаю
постоянное соед. - инициатива сверху.