l.slava

смотрите логи вашего сайта, если там какие-то боты индексируют, то нужно посмотреть приносят они вам трафик на сайт или нет, если нет то банить их. Я на пример забанил вот так через .htaccess RewriteCond %{HTTP_USER_AGENT} ^(snake|snapbot|snoopy|sogou|spacebison|spankbot|spanner|sqworm|superbot) [NC,OR] RewriteCond %{HTTP_USER_AGENT} ^Wget RewriteRule ^(.*)$ 50x.html [L,R=301]

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

То что я сделал: отключил model_tool_image->resize в товарах и категориях, отключил model_catalog_product->updateViewed - так как при апдетах лочится вся таблица, если есть нагрузка на мускуле то это предотвращает блокировку таблицы os_product, еще дополнительно кэшировал запросы по категориям. В некоторых запросах в категориях с LEFT JOIN добавлял SELECT STRAIGHT_JOIN ... так как сортировка очень долго выполнялась 2-4 секунды. Ну и кэш у меня на сутки установлен.

Никогда не слушайте тех кто рекомендуют менять хостинг. В данном случае ваш сайт хорошо индексирует бот яндекса, поставьте Crawl-Delay 5, но бот эту директиву будет использовать не сразу. Сколько у вас в базе товаров? Если больше 10к. то нужно оптимизировать sql запросы и как минимум выставить индексы на базу. По умолчанию в опенкарте не все индексы проставлены.

Вы посмотрите, в каком индексе у гугла находятся ваши страницы page=..., если не в основном то имеет смысл rel=next|prev так как вес страницы останется на главной. А вообще не всегда нужно делать то, что просит гугл :)

Могу вас обрадовать это все "хорошие" base64 - удалять их не нужно. Рекомендую искать по поданным: 1) preg_replace("/.*/e" 2) eval(gzinflate(str_rot13(base64_decode( 3) eval(base64_decode(

Нет, скорее всего сайт уже инфицирован, скопируйте тот контент который вы создавали и установите заново весь код сайта. !!! не копируйте поверх файлы, скорее всего уже есть файлы замаскированные под данный опенкарт.!!! Именно удалите все и заново скопируйте файлы. Если вы видите base64 или eval значит ваш сайт подвержен взлому или с вашего сайта передается какая-то информация.

Проставьте индексы в базе данных будет еще быстрее работать если вы конечно планируете, что кол-во товаров базе будет увеличиваться и будет увеличиваться кол-во посетителей на сайте. А то что вы оптимизировали хорошей производительности не даст.

У вас нет таблицы product_tag. Создайте ее взяв структуру из предыдущего релиза.

Посмотрите access_log (лог доступа к сайту), возможно ваш сайт индексируется ботами или парсерами. И конечно же проверьте ваш код на наличии строки eval(base64, если есть то сайт ваш уязвим.

Если вы видите что к вам загрузили скрипты не относящиеся к opencart это говорит о том что вашем сайте есть уязвимость через которую злоумышленник может сделать с вашими файлами все что угодно. И пока уязвимость не будет устранена, вам будут загружать вредоносный код. Самый простой способ не допустить этого проверяйте все файлы которые вы скачиваете с интернета, в частности шаблоны которые были украдены и выложены в свободный доступ, а также различные модули. В данном случае лучше удалить все файлы и заново установить opencart, предварительно скачав картинки и дамп базы данных. Так как уязвимость может быть замаскирована под обычный код и не профессионал вряд ли его обнаружит.

Ионкуб или Зенд не помогут, если уже украли. Рекомендую покупить лицензионый антивирус на компьютер с которого осуществляется доступ к файлам сайта, а не скачивать с варезных сайтов и не храните пароли во всяких тотал камандерах или файлзилах. Лучше уж сохраните где-то в файле на компе.

Информация в файле catalog/language/russian/common/footer.php

На ссылки 2,3,4.... в теме укажите <a rel="nofollow" href

Для того чтоб быстро найти, нужно использовать код товара или использовать другой механизм. В большинстве случаев 1-2 дня я считаю нормально. Да, если категорий не много, то в кеше особого смысла нет, я когда искал себе магазин я сразу загружал 6 т. категорий и большинство движков и близко не справлялись с таким кол-вом, только opencart примерно на 20 секунд выводил их. По ресайзу: да он один раз ресайзит картинки, но каждый раз проверяет есть ли картинка или нет, у меня на хостинге используется nginx который обрабатывает статику это немного снижает нагрузку на хостинг. А также картинка имеет постоянный url, поисковый трафик на картинки тоже полезен. Плюс кеш храниться в одной папке, которая через время имеет огромный размер и имеет большое кол-во файлов и да зачем дублировать картинки - это только финансовая помощь хостеру, так как места фактически нужно 2 раза больше. :) А вы посчитайте сколько будет файлов сессий, если сайт имеет например 10000 посещений в день + 20000 посещений различными ботами, цифры взял примерно. Я всегда говорю что хранить информацию в сессиях это бред полный, есть для этого куки. Было бы очень правильно если сессии создавались только в том случае если клиент авторизовался/сделал заказ, а не при первом посещении сайта.

На моей практике гугл очень быстро индексирует, день может два. На демо не похоже на sphinx. Я никогда поиском в опенкарте не занимался, но думаю это не проблема. Тестирую sphinx для подбора похожих товаров. Cache_lite меня спасает при 2300 категорий, сам интегрировал в opencart. По поводу ресайза картинок + для тех кто налаживает водяные знаки: я всегда говорю так, если вы планируете на сайте небольшую посещаемость, то пусть это будет на лету, если же посещаемость будет расти, то ни какой сервер не выдержит на лету ресайзить, для примера посмотрите на крупные магазины, никто из них такого не делает. А заранее делать, то с чем потом будет проблемы бесмысленно. Да еще один нюанс, я незнаю какой разработчик в opencart добавил php.ini и указал параметр session.gc_maxlifetime = 12000000; а это 4.5 месяца, сколько будет файлов сессий для одного магазина с хорошей посещаемостью и если учесть что сессия создается и для поисковых ботов (гугл например) и это все сказывается на производительность сервера в целом.

Таки я ввел в заблуждение не 150т. товаров, извините, почти 73т. категорий 2700 - это реально сайчас. Товаров 150т.+6т категорий, это я генерировал для проверки и естественно на сайте сейчас таких цифр нет. Спасибо за хак с пробелом, пофиксил, потому как like c пробелом перебирать все товары это зло.

Поиск не оптимизировал, в поиске показывает не все товары (да, часть товаров у меня оказалась не активна, а я даже не знал :) ), для того чтоб был нормальный поиск нужно ставить sphinx. Или использовать поиск от гугла. По базе данных: `oc_category` индексы на поля "`parent_id` `status` `sort_order` `date_added``date_modified`" `oc_product` => `manufacturer_id` `model` `stock_status_id` `quantity` `author_id` `sort_order` Для кэширования использую Cache_Lite и частично внутренний кэш. В основном кэширую функцию getCategories Отказался от model_tool_image->resize для товаров. Хостинг у nic.ua

В opencart тормозит из-за трех проблем - первая это база данных (нет индексов), вторая это внутренний кэш системы (ф-ция blob). Когда в папке кеша появляется много файлов кеша, то glob(DIR_CACHE . 'cache.*') очень сильно тормозит. Третья это ресайз картинок на лету. Если очень много товаров и категорий это сразу сказывается на работе сайта. Вот мой пример сайта http://magazinknig.com в базе 150т. товаров, около 6 т. категорий.

Последний OpenCart прекрасно справляется с вашими запросами (кое-где в базе только проставить индексы в базе).

А причем здесь ключи? Вы EXPLAIN запроса посмотрите.

Возможно это поможет: нужно немного оптимизировать ORDER BY, то же как раз этим занимаюсь тестирую сейчас запросы с STRAIGHT_JOIN. В магазине 81 тыс. товаров. Да, еще я отключил вообще updateViewed //$this->db->query("UPDATE " . DB_PREFIX . "product SET viewed = viewed + 1 WHERE product_id = '" . (int)$product_id . "'"); это минус 1 запрос к базе.Так как это статистика по большому счету никому не нужна.

Сделал так: в файле catalog/model/catalog/product.php в function getProductRelated сделал не которые изменения: $product_data = array(); //$product_related_query = $this->db->query("SELECT * FROM " . DB_PREFIX . "product_related WHERE product_id = '" . (int)$product_id . "'"); // add $add=""; $temp= $this->db->query("SELECT name FROM " . DB_PREFIX . "product_description WHERE product_id='" . (int)$product_id . "' AND language_id='" . (int)$this->config->get('config_language_id') . "';"); $parts = explode( ' ',trim($temp->row['name'])); foreach( $parts as $part ) { if (strlen($part)>4) { $add .= ' OR LOWER(name) LIKE "%'.$this->db->escape(strtolower(trim($part))).'%" '; } } $add = substr( $add, 4 );$add="( $add )"; $product_related_query =$this->db->query("SELECT pd.product_id as related_id FROM " . DB_PREFIX . "product_description AS pd LEFT JOIN " . DB_PREFIX . "product AS p ON p.product_id = pd.product_id LEFT JOIN " . DB_PREFIX . "product_to_store AS p2s ON p2s.product_id = pd.product_id WHERE $add AND p.status = 1 AND pd.product_id<>'" . (int)$product_id . "' AND p.quantity>'0' AND pd.language_id = '" . (int)$this->config->get('config_language_id') . "' AND p2s.store_id = '" . (int)$this->config->get('config_store_id') . "' GROUP BY pd.product_id LIMIT 4;"); // add foreach ($product_related_query->rows as $result) { Подбирает автоматом похожие товары.

Вот если б разработчики данной системы сделали тесты с кол-вом товаров например 100т. и категорий 10т. они сразу бы увидели бы все баги. А также не все запросы к базе хороши, при определенных условиях их можно оптимизировать, разбить на несколько и т.д. Например на платном хостинге не всегда получиться использовать данную систему, так как будет большая нагрузка как на сервер, так и на базу данных. Еще один момент который хотел упомянуть, есть один магазин ссылка на добавление товаров в корзину выглядит вот таким образом <a class="button_add_small" href="http://мойдомен.ком/index.php?route=checkout/cart&product_id=192848" и некоторые поисковые боты по ней начинают переходить при этом сохраняя свою сессию (не касается яндекса и гугла) в итоге в корзине кол-во товаров становиться равным кол-во товаров в магазине, нагрузка на сервере очень высокая. Размер сессии не вероятных размеров, пришлось писать ограничение.

Что нужно сделать: в папке system/cache/ удалить файлы кэша с категориями. admin/model/catalog/category.php public function getCategories($parent_id) за коментируйте //$this->cache->set('category.' . $this->config->get('config_language_id') . '.' . $parent_id, $category_data); Почему? Ф-ция glob безумно тормозит при кол-ве файлов кэша более 1000 Еще в админе Уровень сжатия: установите в 0, если у вас не очень мощный сервер. Должно чуток быть легче. В mysql включите логирование медленных запросов, например log-slow-queries = slow.log long_query_time = 1 log-queries-not-using-indexes оптимизируйте те запросы которые очень медленные.