Увеличение скорости работы компонента - AutoBB

Когда в моей базе, количество объявлений перевалило далеко за тысячу, хостер начал мне жаловатся, что мой сайт сильно грузит его сервер.
После добавления нескольких индексов, серверу стало ЛЕГЧЕ!

Предлагаю в этой теме обменяться опытом по оптимизации скорости работы компонента.
ПОДЕЛИТЕСЬ кто какие шаги предпринимал в этом направлении.
Или может быть есть мысли чего можно было бы поменять для ентого.

---------------------
Какие индексы я добавил (по крайней мере у меня их не было):

ALTER TABLE `jos_autobb_messages`
  ADD INDEX `createDate` ( `createDate` ),
  ADD INDEX `expirationDate` ( `expirationDate` ),
  ADD INDEX `vendor` ( `vendor` ),
  ADD INDEX `model` ( `model` ),
  ADD INDEX `city` ( `city` );

ALTER TABLE `jos_autobb_msg_complect`
  ADD INDEX `msgid_complectid` ( `msgid`, `complectid` );

ALTER TABLE `jos_autobb_photos`
  ADD INDEX `msgid` ( `msgid` );

добавлено позже:

ALTER TABLE `jos_autobb_extsearch`
  ADD INDEX `searchParam` ( `searchParam` ( 200 ) );

добавлено позже - Alex Revo:
ALTER TABLE `jos_autobb_messages` ADD INDEX `state` ( `state` );

Если индексы добавляются на рабочую базу, то желательно еще выполнить следующие команды:

OPTIMIZE TABLE `jos_autobb_messages`;
OPTIMIZE TABLE `jos_autobb_extsearch`;
OPTIMIZE TABLE `jos_autobb_msg_complect`;
OPTIMIZE TABLE `jos_autobb_photos`;

Для оптимизации   процесса вывода списка объявлений с фотографиями,
я сделал чтобы для каждого объявления, хранился файл с иконкой.
А при выводе списка объявлений, в качестве URL передается прямая ссылка на этот файл.
Что это дает:

Преимущества:

1. Избегаем вызова index2.php c &task=='photo' для каждого объявления с фото, выводимого в списке.
   Таким образом не делается дополнительной php-сессии на сервере, для получения изображения.

2. Не делаем каждый раз вызова функции LoadPhoto (делается однажды для каждого объявления),
   внутри которой, для каждой фотографии, ВСЕГДА делается ТРИ sql-запроса к mysql.
      - первый получает имя файла для фотографии;
      - второй получает категорию автомобиля, для данного объявления;
      - третий загружает конфигурацию для этой категории.
   А также не занимаемся преобразованием графического файла, внутри этой функции, в нужный нам размер.

3. Прямые URL на файлы с фото, всегда работают быстрее, и лучше кэшируются на локальной машине посетителя сайта.

Недостатки:

1. Создаются дополнительные файлы на сервере.
   Но они небольшого размера, и всего по одному файлу на каждое объявление.

Реализация этого решения приведена в моем сообщении:
http://joomlaforum.ru/index.php/topic,21865.msg127960.html#msg127960

Избегаем вызова index2.php c &task=='photo' для каждого объявления с фото, выводимого в списке.

А этого достаточно?
Вызов index2.php происходит при просмотре конкретного объявления, в модуле последних объявлений, их тоже  нужно оптимизировать?

А этого достаточно?
Вызов index2.php происходит при просмотре конкретного объявления, в модуле последних объявлений, их тоже  нужно оптимизировать?

модуль последних объявлений выводится только на главной странице,
поэтому не считаю целесообразным его переделывать

важно уменьшить нагрузку на сервер при массовых операциях!
например таких как показ маленькой фотографии в списках объявлений

модуль последних объявлений выводится только на главной странице,
поэтому не считаю целесообразным его переделывать

важно уменьшить нагрузку на сервер при массовых операциях!
например таких как показ маленькой фотографии в списках объявлений

На http://autobb.ru/ - с главной страницы прямые ссылки на изображения идут.
Быстрее все-таки открываеться, чем с вызовом index2.php.
Surik, может поможешь?

На http://autobb.ru/ - с главной страницы прямые ссылки на изображения идут.
Быстрее все-таки открываеться, чем с вызовом index2.php.
Surik, может поможешь?

ты повнимательнее посмотри на эти так называемые прямые ссылки!!!
это дурилово
попробуй обратится к таким ссылкам:
http://www.autobb.ru/images/com_autobb/custom/200/914.jpg
http://www.autobb.ru/images/com_autobb/custom/189/914.jpg
http://www.autobb.ru/images/com_autobb/custom/123/914.jpg
http://www.autobb.ru/images/com_autobb/custom/95/914.jpg
http://www.autobb.ru/images/com_autobb/custom/80/914.jpg
http://www.autobb.ru/images/com_autobb/custom/55/914.jpg
и т.д.
и видим что сайт выдает одну и ту же фотографию запрошенного размера.
я сильно сомневаюсь, что там каждая фотка лежит во всех мыслимых размерах 

Это НЕ ПРЯМАЯ ссылка на фото, а просто перехват строки запроса, и выдача нужного контента.
Там скорее всего нету заранее заготовленных картинок, а выдаются они динамически
запрошенного размера.
А сделано это скорее всего для лучшей индексации картинок поисковыми серверами.
Поэтому скорость выдачи картинок на сайте с помощью такой технологии,
по моему мнению, НЕ УВЕЛИЧИВАЕТСЯ.

Поэтому скорость выдачи картинок на сайте с помощью такой технологии,
по моему мнению, НЕ УВЕЛИЧИВАЕТСЯ.

Абсолютно согласен с Surikом!
Лучше, по моему мнению, при публикации объявления ресайзить фотографии и аттачить прямые ссылки на фотографии к ID объявления.

А вот я не согласен с Surik'ом. ссылки сформированы так и фотографии реально лежат в этих местах.
Ты прав на счет "перехват строки запроса, и выдача нужного контента", с одним НО:
для незнакомых с mod_rewrite поясню, если запрошенный файл не найден, то запрашивается index2.php с нужными параметрами И фотография сохраняется по запрошенному адресу. Дальше уже открывается существующий файл. Нагрузка снижается в разы, как и писал Surik.
Такое решение я применил, потому что я могу менять размеры фото в модулях, а все размеры сразу предусмотреть невозможно.

А вот я не согласен с Surik'ом. ссылки сформированы так и фотографии реально лежат в этих местах.
Ты прав на счет "перехват строки запроса, и выдача нужного контента", с одним НО:

Код

RewriteCond %{REQUEST_URI} ^/images/com_autobb/.*	[NC]
RewriteCond %{REQUEST_FILENAME} !-f

для незнакомых с mod_rewrite поясню, если запрошенный файл не найден, то запрашивается index2.php с нужными параметрами И фотография сохраняется по запрошенному адресу. Дальше уже открывается существующий файл. Нагрузка снижается в разы, как и писал Surik.
Такое решение я применил, потому что я могу менять размеры фото в модулях, а все размеры сразу предусмотреть невозможно.

Очень интересное решение, Павел!
Я поначалу подумал что так оно и сделано.
Но потом мне пришла мысль что такой подход, наряду с явными плюсами,
страдает одним отрицательным свойством:
Появляется возможность устроить атаку на сайт, и забить его жесткий диск до отказа.
Если я правильно понял, то если к фоткам обращатся так, как указано в моем предыдущем
посте, то можно каждую фотку расплодить на сервере под каждый размер с шагом в 1px
Очень быстро забьется весь винт на серваке  

ну так скажем винт забьется не скоро, да и трафика вы мне исходящего столько нагенерите, что я буду только благодарен (у мастерхоста же соотношение 1:4). Но теоретически возможно
P.s. Однако поглядите
- картинки шириной 50px у меня используется на сайте
- картинок шириной 55px у меня на сайте нету

все-таки RewriteCond может многое

Добавил еще индекс для поля Состояние авто (см.первый пост).

Можно с помощи скрипта  при поиск ограничить исходящы резултаты на 200 для облекчения перегрузка сервер?

Можно с помощи скрипта  при поиск ограничить исходящы резултаты на 200 для облекчения перегрузка сервер?

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

Рекомендую всем попробовать в работе Мамбот кеширования страниц сайта System-Cache (для Joomla!1.0)
http://joomlaforum.ru/index.php/topic,35163.0.html

Мои первые пробы показали, что с Autobb он работает без нареканий, скорость загрузки страниц возрастает до 40%.

В связи с обновлением мамбота System-Cache в версии 1.1
Рекомендую указать в нем следующие оптимальные настройки для компонента.
Не кешировать:
com_autobb|myads
com_autobb|edit
com_autobb|apply
com_autobb|wwwmail
com_autobb|publish
Очищать кеш:
com_autobb|save
com_autobb|delete
com_autobb|publish

а как на счет настороек для версии 1.7 System-Cache (для Joomla!1.0)   

com_autobb|myads|nocache
com_autobb|edit|nocache
com_autobb|apply|nocache
com_autobb|wwwmail|nocache
com_autobb|publish|nocache
com_autobb|delete|clear

Спасибо за  ответ. Как я понимаю ето записываем в ячейку "Действия для сайта"

да

Подскажите еще пожалуйста как и куда добавить индексы? Какой принцип их работы? Может ссылка есть кокаята на подобный материал, поиск не дал результатов. Спасибо

Индекс (англ. index) — объект базы данных, создаваемый с целью повышения производительности выполнения запросов. Таблицы в базе данных могут иметь большое количество строк, которые хранятся в произвольном порядке, и их поиск по заданному значению путем последовательного просмотра таблицы строка за строкой может занимать много времени. Индекс формируется из значений одного или нескольких столбцов таблицы и указателей на соответствующие строки таблицы и, таким образом, позволяет находить нужную строку по заданному значению. Ускорение работы с использованием индексов достигается в первую очередь за счёт того, что индекс имеет структуру, оптимизированную под поиск - например, балансированного дерева. Некоторые СУБД расширяют возможности индексов введением возможности создания индексов по выражениям. Например, индекс может быть создан по выражению upper(last_name) и соответственно будет хранить ссылки, ключом к которым будет значение поля last_name в верхнем регистре. Кроме того, индексы могут быть объявлены как уникальные и как неуникальные. Уникальный индекс реализует ограничение целостности на таблице, исключая возможность вставки повторяющихся значений.



Кажетса разобралса, и запросы делаю в режиме SQL-запрос (ы) к базе данных
 
Всем Удучи!

Подскажите теперь пожалуйста как удалить эти индексы,  ато у меня теперь не одно новое объявление не выводится, пишет    Too many pages.?  Это запись от Artio joomsef. Подскажите. Заранее  Спасибо

Может просто нужно очистить кеш и все ссылки

Нет чистка кеша не помогла, но после включения и выключения компонента артио джумсеф всьо стало на свои места, но ссилки все перезаписались. Упустил этот  нюанс, теперь куча гемороя. И все таки  как удалить индексы. С каким СЕФ компонентом дружит АВТОББ?

Со стандартным СЕФом хорошо дружит. Удалить можно также, как и добавили, запросом к базе, но на СЕФ это не влияет это точно.

спустя 2 дня работы вижу сильно я бы даже сказал ужасное торможение. Не понимаю, с чем связано, тк и при снятии с пупликации бота скрость загрузки низкая. Объём папки кэш (количство файлов) стало больше наверное, раз в 5. Очищаю, но все равно медленно. Медленно - это 4-5 секунд

Если индексы убрали то база будет тормозить все.

Индексы не убирал. У меня последняя 1.8 версия, индексы там такие же, как и для 1.7 ?? Joomla 1.0

проблема решена: страницы загружались очень медленно по причине неработы сервиса рамблера, (не работал в течении дня сайт и все сервисы по причине отсутствия питания на площадке размещения серверов). Так как на сайте стоят счетчики Рамблера, и рекламный блок Бегуна, то это привело к медленной загрузке страниц.