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 оптимизируйте те запросы которые очень медленные.