Тормозит ужасно [решено]

[alexxxus]

Добрый день.

Структура магазина содержит 15 000 категорий, тройная вложенность. Тормоза на стадии открытия, долго-долго (минут 15-20) кеширует категории, прежде чем открывается главная.

При этом категории пока еще даже не содержат товаров (планируется по 5-7 товаров в каждой категории).

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

Двиг (ocstore 1.5) стоит на Денвере, но тут, наверное, никакой супер-хост не поможет...

Это как-нибудь лечится или это конструктивный недостаток? Жаль,если это так, а хотелось поработать именно с этим движком.

[alexxxus]

Это что за магазин такой? =)

Отключи вывовод списка категорий для поиска в header. И будет летать.

Спасибо за быстрый ответ.

Буду пробывать. (Магазин покажу конечно, когда будет готов.)

[alexxxus]

Да, отключение категорий в хедере решило проблему с тормозами.

Супер, спасибо за помощь.

[boomfox]

я после удаления, все равно не получил желаемый результат. Кроме того, при добавлении категории, нужно ждать примерно секунд 30 (и с каждым разом больше) что бы список категорий обновился. А когда открываешь сайт, то может грузиться тоже секунд 30.

Змінено 1 серпня 2016 користувачем shoputils
Сайта больше не существует

[alexxxus]

я после удаления, все равно не получил желаемый результат. Кроме того, при добавлении категории, нужно ждать примерно секунд 30 (и с каждым разом больше) что бы список категорий обновился. А когда открываешь сайт, то может грузиться тоже секунд 30.

Все летает у тебя там на сайте.Наверное, кеш не почистил сразу... (удалить все в папке system/cache) А счас кеш обновился (1 раз в час) и все заработало.Я отключал категории через catalog/controller/common/header.phpзакомментировал строку $this->data['categories'] = $this->getCategories(0);сделал$this->data['categories'] = array(); // $this->data['categories'] = $this->getCategories(0); Змінено 1 серпня 2016 користувачем shoputils
Сайта больше не существует

[boomfox]

Удалил все из кэша, там было больше 3000 файлов, сайт вроде начал быстрее работать. Но возник еще один вопрос, я когда добавляю новую категорию, то обновление, после того как нажал кнопку сохранить, занимает примерно 30 секунд, это можно ускорить? Или лучше не трогать, и что нужно периодически делать, чтобы сайт постоянно работал быстро?

[boomfox]

Все равно сайт ужасно тормозит, кто-то же с этим сталкивался и как-то боролся, помогите будьте добры, кто знает.

[boomfox]

""Я отключал категории через catalog/controller/common/header.php

закомментировал строку

$this->data['categories'] = $this->getCategories(0);

сделал

$this->data['categories'] = array(); // $this->data['categories'] = $this->getCategories(0); """

Это и вправду был выход, большое спасибо!

[l.slava]

Все равно сайт ужасно тормозит, кто-то же с этим сталкивался и как-то боролся, помогите будьте добры, кто знает.

Что нужно сделать:

в папке 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

оптимизируйте те запросы которые очень медленные.

[remix8080]

Отключи вывовод списка категорий для поиска в header. И будет летать.

А стоит ли такое попробовать при кол-ве товаров чуть больше тыщи и при ~150 категориях? В смысле, ощутимо ли будет на "летучести" магазина?

Или не стоит пробовать?

П.С. Сам еще не пробовал, думаю, может кто-то уже экспериментировал :rolleyes:

[alexxxus]

Что нужно сделать:

в папке 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

оптимизируйте те запросы которые очень медленные.

Да. Это помогло. Действительно, индексация всех спасет.

Спасибо I.Slava - очень помог в решении проблемы. Терзал его ЛС. как оказалось - не зря :rolleyes:

Что я делал: подключил логирование медленных запросов, как было написано.

На денвере идем в usr/local/mysql-5.1/my.cnf

Ищем строчку [mysqld]. После нее пишем:

log-slow-queries = slow.log

long_query_time = 10

log-queries-not-using-indexes

Логирование включили. Файл с логом будет в data/slow.log

Запускаем свой тормозящий сайт, ходим туда сюда по нему.

Смотрим лог. Находим тормозеые поля.

Идем в PhpMyAdmin.

Открываем табличку с тормозами, во вкладке СТРУКТУРА. Напротив каждого поля есть кнопочки. Напртив плохого поля нажимаем

кнопочку ИНДЕКСИРОВАТЬ.

Повторяем действия со всеми остальными плохими полями в других таблицах.

После этой процедуры магазин с 43000 товарами и общем кол-вом

записей 1,057,814 стал летать как пустой магазин в демо-режиме.

А до этого главная стр. магазина открывалась больше минуты. :rolleyes:

Что читал http://habrahabr.ru/blogs/mysql/31072/

[alexxxus]

затупил

[l.slava]

Вот если б разработчики данной системы сделали тесты с кол-вом товаров например 100т. и категорий 10т. они сразу бы увидели бы все баги.

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

Еще один момент который хотел упомянуть, есть один магазин ссылка на добавление товаров в корзину выглядит вот таким образом

<a class="button_add_small" href="http://мойдомен.ком/index.php?route=checkout/cart&product_id=192848"

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

[Sammy95]

Вот если б разработчики данной системы сделали тесты с кол-вом товаров например 100т. и категорий 10т. они сразу бы увидели бы все баги.

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

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

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

<a class="button_add_small" href="http://мойдомен.ком/index.php?route=checkout/cart&product_id=192848"

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

А здесь уже косяк шаблона, ИМХО. Чтобы боты не ходили по некоторым ссылкам, их надо делать в виде форм или яваскрипта, AFAIK. Или это в дефолтном шаблоне?

[Sammy95]

Не могу понять чей это псевдоним, какой таблицы: mcd

oc_length_class_description

[UncleAndy]

Открываем табличку с тормозами, во вкладке СТРУКТУРА. Напротив каждого поля есть кнопочки. Напртив плохого поля нажимаем

кнопочку ИНДЕКСИРОВАТЬ.

Повторяем действия со всеми остальными плохими полями в других таблицах.

После этой процедуры магазин с 43000 товарами и общем кол-вом

записей 1,057,814 стал летать как пустой магазин в демо-режиме.

А до этого главная стр. магазина открывалась больше минуты. :rolleyes:

ПЛИИИЗЗЗ!!! Напишите какие поля в каких таблицах индексировали! Мы их просто добавим в БД что-бы всем было хорошо. :)

Ну или если в лом - хотя-бы дамп структуры базы данных. :)

[alexxxus]

ПЛИИИЗЗЗ!!! Напишите какие поля в каких таблицах индексировали! Мы их просто добавим в БД что-бы всем было хорошо. :)

Ну или если в лом - хотя-бы дамп структуры базы данных. :)

Универсальный рецепт - самое безотказное, простое и действенное - поставить индексы у всех таблиц на всех полях, которые содержат в названии '_id' и не имеют вообще никаких индексов.

Плюс те поля oc_product, которые участвуют в выборках (sort_order, status и проч), для этого смотреть SQL-запросы в скрипте или в логах медленных запросов.

Ну и по аналогии другие поля в таблицах, по которым идет select

[EvzeNsx]

когда слишком много индексов - это даже хуже, чем если их вообще нет)

[UncleAndy]

когда слишком много индексов - это даже хуже, чем если их вообще нет)

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

[EvzeNsx]

Совершенно верно.

[Sammy95]

ПЛИИИЗЗЗ!!! Напишите какие поля в каких таблицах индексировали! Мы их просто добавим в БД что-бы всем было хорошо. :)

Давай только без подобного фанатизма :) Уж лучше совсем ничего не трогать, чем вот так в слепую по принципу "это помогло одному из пользователей, давайте это же в дистрибутив запихнём".

[alexxxus]

Давай только без подобного фанатизма :) Уж лучше совсем ничего не трогать, чем вот так в слепую по принципу "это помогло одному из пользователей, давайте это же в дистрибутив запихнём".

Я не зря написал, что надо смотреть логи СВОИХ МЕДЛЕННЫХ ЗАПРОСОВ. СВОЕГО КОНКРЕТНОГО МАГАЗИНА.

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

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

хотя на первый взгляд вроде не надо было. А получилось, что очень надо :unsure:

Но большинство '_id' полей хочет индекса, если эти поля задействованы в вашем магазине.

Другие нужные поля можно найти в SELECT -ах в логах медленных запросов.

[UncleAndy]

Давай только без подобного фанатизма :) Уж лучше совсем ничего не трогать, чем вот так в слепую по принципу "это помогло одному из пользователей, давайте это же в дистрибутив запихнём".

Ну, естественно, я не собираюсь все переносить автоматически. Естественно, я буду смотреть логику.

И, кстати, когда разбирал структуру базы был удивлен небольшим количеством индексов. Как пишет alexxxus, поля типа "*_id", по идее, обязаны иметь индекс т.к. служат для связи между таблицами. А если это кроме моих "теоритических" предположений еще и подтверждается на большой базе, я просто не вижу что здесь обсуждать (вернее, что обсудить - есть всегда, просто в данном конкретном случае мне кажеться все очевидным).

[Sammy95]

Ну, естественно, я не собираюсь все переносить автоматически. Естественно, я буду смотреть логику.

Этого недостаточно, нужна ещё и большая база (а лучше - несколько) для тестов в живую. А логику и без этого можно посмотреть.

[UncleAndy]

Этого недостаточно, нужна ещё и большая база (а лучше - несколько) для тестов в живую. А логику и без этого можно посмотреть.

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