Хотелось бы узнать, кто на практике реально перешел на постоянные соединения с БД, какие проблемы возникали, и насколько это отразилось на скорости и загрузки сервера? Ознакомился еще слабо, пока наслышан только плюсами.. хотя вот: http://ru2.php.net/manual/ru/function.m ... .php#85670 Просто у нас сервер иногда испытывает жесткие нагрузки (начал), и чтобы их найти - нужно время. Кол-во посетителей увеличилось в 1,5 раза, да и дописано различного много. Кроме отыскивания "долгих" участков, реально задумываюсь о повышении производительности. В частности - mysql_pconnect() (тока для mysqli, так и не понял как там), memcache. Кстати, у нас баннерная сетка - на странице может быть 5 баннеров одновременно. Все они подключаются через <iframe> и вызывается скрипт. На показ баннера выполняется 4 запроса. Итого 20 запросов тока на баннерку с 1 страницы, а если еще учесть что одновременно может просмотреть несколько пользователей... Заметил, что если использовать ключ 1 на несколько полей (скажем public, date_time), чем каждый на каждое поле - выборка идет быстрей, правда добавление/изменение стало заметно подтормаживать, хотя непонятно, по этой ли причине или от нагрузки на сервер все тормозит. Правда выборки бывают очень различные, с очень разными полями... Вот пример: есть выборка где в WHERE стоит public & date есть выборка где в WHERE стоит public & date & article есть выборка где в WHERE стоит public & date & n_top есть выборка где в WHERE стоит public & date & n_main как граммотно проставить ключи в таком случае? Большое спасибо.
Не там ищете Зачем 4-то? Баннеры разноформатные? А iframe'ы зачем? Что ж вы нелюбопытные-то такие? Самый простой способ: взять и попробовать, поставить эксперимент. И станет понятно чего и как делать. Т.е. попробовать делать разные индексы и смотреть explain'ом. Сделать замер времени с индексом и без него, потом оценить результаты.
AlexGousev спасибо баннеры разноформатные (GIF,JPEG,SWF разл. размеров), iframe - защита от роботов (накручивают конкретно) + сайт мультидоменный. Запросов даже 5: 1 - возвращает массив описывающий размещение для показа 2 - сам баннер на данном месте 3 - INSERT INTO ad_statistic_evn - фиксирует событие 4 - фиксирует статистику для баннера 5 - фиксирует статистику для места. Писал баннерку не я. Т.е. pconnect не сильно поможет?
Если есть уверенность, что проблема именно в баннерах, то стоит, как минимум, объеденить запросы 3, 4 и 5. Причем, не «как записать одним заапросом сразу в три таблицы», а именно сделать одну таблицу и статистику вести на ее основе. Надеюсь, в таблицах статистики индексов нет
да не поддерживает оно нормально сие. сколько можно писать? НЕ ПОДДЕРЖИВАЕТ. Б Л Я! реально, нормальные пацаны пишут так, что б оно свистело при любых раскладах, а то хоть 100 коннектов держи, а дебильный SQL положит всю базу намертво.
440Hz а я уже увеличил max_connections до 200, иначе не хватает AlexGousev индексов нет Думаю, чтоб такое реализовать надо конкретно баннерку переделывать, так что пока отпадает значит persistent connection отпдадает, будем искать медленные участки и смотреть в сторону memcache Всем спасибо