Уменьшение нагрузки

[dj_fat]

Какими способами можно уменьшить нагрузку в coppermine?
Я использую практически минимум:
У меня отображается по 6 альбомов на каждую страницу, страниц 5-6 (старые альбомы просто удаляю потом), альбом состоит обычно из 100-200 фото, комменты и голосования закрыты, добавляю фотки только я, регистрация закрыта, при просмотре альбома убрана сортировка, нет информации об изображениях, короче я абсолютно всю ерудну убрал и заходя на галлерею можно посмотреть фотки и всё.
Грубо говоря, мне нужна Light-версия движка  так как от хостера идёт инфа, что нагрузка превышается.
Вот ссылка на саму галлрею.

[MISHA]

Если учесть, что у вас не отображаются случайные файлы (глянул ваш сайт) то нагрузка вообще минимальная. Сколько у вас онлайн?
Есть попытка оптимизации count-запросов   http://forum.coppermine-gallery.net/index.php/topic,52342.0.html
p.s. Может вообще косячит хостер?

[dj_fat]

Спасибо, MISHA. Щас прочитаю и дополню от себя как проблема обнаружилась:

В общем, проблема произошла у другого хостера сначала, те вообще сказали у вас нагрузка третий раз возникла за всё обслуживание, мы вас предупреждали, а вы ничего не сделали, значит до свидания, это у multihost такая логика, хотя нагрузки возникали по разным причинам в течении года и ошибки исправлялись. А вот последняя относительно галлереи в конце января появилась, причём не на мускул, а на загрузку процессора, в присланном письме фигурировали файлы foto/displayimage.php, foto/thumbnails.php, foto/index.php. На тот момент coppermine был интегрирован в joomla и ещё на главную страницу jooml'ы через модуль 5 случайных фото выводилось с подписью из какого альбома каждое фото. В общем после переезда получил практически сразу предупреждение о нагрузке от нового хостера mchost с теми же файлами, только добавился к списку ещё foto/addfav.php, каким макаром он вообще оказался задействован я не понимаю. Переговорил с тех.поддержкой, сказали где-то у вас проблема, что вам не поможет даже VPS, так как физическая нагрузка до 87 процентов доходит, в общем я перешёл всё равно на более дорогой тариф, теперь порог нагрузки не 5%, а 15%, потом убрал интеграцию в joomla, сократил кол-во с random фото модуля на главной сайта до 4, там же убрал подписи альбомов, в самой галлерее убрал 50 альбомов в архив, обновил движок до 1.4.20 и включил, вроде всё нормально но через панель хостера видно что нагрузка проскакивает, когда coppermine отключен её нету.

P.S. В Joomla тоже покопался, включил кэш, покромсал лишнее.

[dj_fat]

Забыл написать, посещаемость судя по счётчикам обычно 400-500 в день.

[seaterror]

// форум у Вас вообще мертвый лежит 

прикольная галерея )) и работает вроде как быстро, может у Вас включено какое то кэширование? сжатие? и т.п.?
так то по идее возможно мост интеграции мог грузить неплохо (( но вы говорите  что его отключили   

//ссылку меню список альбомов, лучше думается перебить с /foto/index.php?cat=0  на  /foto/index.php  а то получается вроде как 2 адреса ведут на главную, ну это на любителя ))

[dj_fat]

2 seaterror:
Форум не мертвый, это я просто забыл после удаления моста ссылку в шаблоне галлереи исправить, уже изменил. Мост я удалил, так как нагрузка поменьше хоть стала.
Список альбомов - это как главная, у меня ведь нет категорий, а только альбомы.
Кэширование не включено никакое, сжатие тоже.

[Makc666]

• Включить режим отладки - Да:Только админы
• Отображать сообщения в режиме отладки - Да

Увидите список запросов в базу данных внизу.
Берёте запросы и в phpmyadmin отправляете.
И смотрите на "запрос занял 0.0008 сек.".

[Petrovichalt]

Подниму темку, т.к. проблема стала актуальной.
Имеется галерея: 41848 файлов в 782 альбомах и 157  категориях.
В последнее время хостер стал часто отрубать ресурс, ссылаясь на чрезмерную нагрузку. Судя по данным которые дал для информации, нагрузку дают поисковые роботы, каждый раз разные. Закрыл доступ в htaccess указанным роботам. Но проблема повторяется периодически, и каждый раз новый паук, все же их не перебанить :'(
В галерее включен мост с форумом phpbb, случайные файлы - 10 шт., последние добавления - 10 шт.
Согласно отладочной инфы загрузка главной страницы: Page generated in 3.942 seconds - 218 queries in 2.621 seconds
Из логов видно ясно, что основную нагрузку боты дают при переходе по ссылкам - displayimage.php?album=toprated&cat=116&pos=78, я так понял это ссылки на изменение рейтинга фотографий.
Тех. поддержка хостера указала на такой момент: Как правило подобные проблемы возникают из-за большого количество не оптимальных дисковых операций.
Читал темку попытки оптимизации count запросов, но к реальному применению еще не дошел. Какие действия еще можете предложить, посоветовать? Возможно слишком много файлов в галерее и под такой объем галерея не заточена?

[Makc666]

Из логов видно ясно, что основную нагрузку боты дают при переходе по ссылкам - displayimage.php?album=toprated&cat=116&pos=78, я так понял это ссылки на изменение рейтинга фотографий.

Это ссылка(и), которые отображаются в блоке "Лучшие по рейтингу".

Реально в 1.4.* или нужно отключать данный блок вообще. Или модифицировать код галереи, чтобы для гостей это не отображалось.

В 1.5.* появилась возможно для каждой группы или в настройках галереи для гостей выбирать уровень доступа:

Разрешить доступ без входа (гости или анонимные пользователи)

• Нет
• Да: только миниатюры
• Да: миниатюры и промежуточные изображения
• Да: миниатюры, промежуточные и полноразмерные изображения

[Petrovichalt]

В 1.5.* появилась возможно для каждой группы или в настройках галереи для гостей выбирать уровень доступа:

Я так предполагаю, что на RC версию пока не стоит переходить и дождаться финал-релиза?

Тех. поддержка хостера указала на такой момент: Как правило подобные проблемы возникают из-за большого количество не оптимальных дисковых операций.

По этому вопросу нет ничего из решений, предположений? Понимаю, что галерея выросла за 3 года до большого объема, но не удалять же старые фото (на крайний случай будем рассматривать и такой вариант)?

[Makc666]

Я так предполагаю, что на RC версию пока не стоит переходить и дождаться финал-релиза?

Вопрос не для этой темы
Разработчики не рекомендуют...

По этому вопросу нет ничего из решений, предположений? Понимаю, что галерея выросла за 3 года до большого объема, но не удалять же старые фото (на крайний случай будем рассматривать и такой вариант)?

Запрос в базу данных не может вызывать "не оптимальные дисковые операции". У вас размер таблицы с изображениями не такой большой уж быть должен, чтобы говорить о подобном.

Как я думаю, строка вида, а точнее запрос:
displayimage.php?album=toprated&cat=116&pos=78
плох(а) тем, что не указывается точный номер изображения. Указывается его позиция.
А значит эти позиции нужно посчитать.

В 1.5 указывается сразу уникальный номер изображения:
displayimage.php?album=toprated&cat=0&pid=49#top_display_media



А теперь к Вам самый главный вопрос.
Как выглядит настройка вашей галереи в конфигурации, где указана переменная toprated.

Отображение списка альбомов -> Содержание главной страницы

Скопируйте сюда.

Просто в вашей ссылки отображается позиция 78 (&pos=78).
У меня сомнения, что эта ссылка генерируется из блока "Лучшие по рейтингу".

Скорее всего эта ссылка берется со страницы "Лучшие по рейтингу".
http://coppermine-gallery.net/demo/cpg14x/thumbnails.php?album=toprated&cat=0



Откройте файл
include/functions.inc.php

Там есть функция:

Code Select Expand

case 'toprated': // Top rated pictures

Да и замените строку:

Code Select Expand

$query = "SELECT COUNT(*) from {$CONFIG['TABLE_PICTURES']} WHERE approved = 'YES' AND votes >= '{$CONFIG['min_votes_for_rating']}' $META_ALBUM_SET";

На строку:

Code Select Expand

$query = "SELECT COUNT(*) from {$CONFIG['TABLE_PICTURES']} WHERE approved = 'YES' AND votes >= '{$CONFIG['min_votes_for_rating']}' $META_ALBUM_SET ORDER BY pic_rating DESC, votes DESC, pid DESC LIMIT 0,100";

Данное ограничение в 100 изображений повлияет так же и на вывод на главной странице.

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

На torrents.ru , как я понимаю, то же с этой проблемой столкнулись.
Там просто отображаются страницы не считая количество изображений.

Я тут попытался нечто похоже сам написать, но что-то где-то в логике не смог додумать.
Легче поискать код в исходниках трекера

[Petrovichalt]

Да, Макс, по всей видимости ты прав,

Скорее всего эта ссылка берется со страницы "Лучшие по рейтингу".

т.к. блока "Лучшие по рейтингу" на главной странице галереи нет.
Вот как выглядит настройка "Отображение списка альбомов -> Содержание главной страницы" - breadcrumb/catlist/alblist/random,2/lastup,2
пару строк случайных картинок и пару из последних добавленных.

[Petrovichalt]

Сделал изменения, о которых ты написал. Не заметил визуально никакой разницы в ограничение на 100 изображений.
Или это ограничение только на выборку 100 файлов за один запрос?
Страниц с фото "Лучшие по рейтингу" около 400.
В настройках галереи значение пункта "Минимальное количество голосов для файла, чтобы он появился в списке 'Лучшие по рейтингу'" - 1.
Увеличивать значение в количестве голосов к примеру до 3-х для попадания на страницу "Лучшие по рейтингу" не желательно по отношению к пользователям, а вот по соотношению к нагрузке это даст какой-то эффект?

[Makc666]

Сделал изменения, о которых ты написал. Не заметил визуально никакой разницы в ограничение на 100 изображений.

А что значит визуально? И где не заметили?

Или это ограничение только на выборку 100 файлов за один запрос?

Если я не ошибаюсь, я не знаю, ошибаюсь я или нет, к сожалению, надо почитать документацию, то LIMIT - это указание базе данных, остановится после того, как она выбрала 100 записей, подходящих под заданное условие.

Как Вы понимаете, что база данных будет выбирать 100 или 1000, условия будет одно и тоже. И если сам процесс выборки по какой-то причине медленный, то может быть что подобное ограничение и не будет приносить должного результата.
Я так думаю.

Про сам LIMIT написано тут - http://dev.mysql.com/doc/refman/5.1/en/select.html
Про оптимизацию LIMIT написано тут - http://dev.mysql.com/doc/refman/5.1/en/limit-optimization.html
Про SELECT и его скорость тут - http://dev.mysql.com/doc/refman/5.1/en/select-speed.html

Страниц с фото "Лучшие по рейтингу" около 400.

Это не совсем понял. Страницы - это страницы. А количество изображений выбираемых запросом - это совершенно другое.

В настройках галереи значение пункта "Минимальное количество голосов для файла, чтобы он появился в списке 'Лучшие по рейтингу'" - 1.
Увеличивать значение в количестве голосов к примеру до 3-х для попадания на страницу "Лучшие по рейтингу" не желательно по отношению к пользователям, а вот по соотношению к нагрузке это даст какой-то эффект?

Да кто ж его знает, поможет или нет.
Любое сужение ограничения, по идее, это небольшой выигрыш в скорости.
При этом, если та колонка, по которой идёт ограничение, имеет индекс, то тогда выборка идёт намного быстрее.