Перейти до вмісту
Пошук в
  • Детальніше...
Шукати результати, які ...
Шукати результати в ...

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


Recommended Posts

Добрый день.

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

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

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

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

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

Надіслати
Поділитися на інших сайтах


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

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

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

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

Надіслати
Поділитися на інших сайтах


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

Змінено користувачем shoputils
Сайта больше не существует
Надіслати
Поділитися на інших сайтах


я после удаления, все равно не получил желаемый результат. Кроме того, при добавлении категории, нужно ждать примерно секунд 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); Змінено користувачем shoputils
Сайта больше не существует
  • +1 1
Надіслати
Поділитися на інших сайтах


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

Надіслати
Поділитися на інших сайтах


  • 2 months later...

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

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

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

сделал

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

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

Надіслати
Поділитися на інших сайтах


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

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

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

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

Надіслати
Поділитися на інших сайтах


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

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

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

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

Надіслати
Поділитися на інших сайтах


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

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

  • +1 1
Надіслати
Поділитися на інших сайтах


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

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

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

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

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

Надіслати
Поділитися на інших сайтах


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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

Надіслати
Поділитися на інших сайтах


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

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

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

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

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

Надіслати
Поділитися на інших сайтах


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

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

Надіслати
Поділитися на інших сайтах


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

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


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

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

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

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

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

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

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

Надіслати
Поділитися на інших сайтах


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

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

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

Надіслати
Поділитися на інших сайтах


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

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


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

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

Надіслати
Поділитися на інших сайтах


Створіть аккаунт або увійдіть для коментування

Ви повинні бути користувачем, щоб залишити коментар

Створити обліковий запис

Зареєструйтеся для отримання облікового запису. Це просто!

Зареєструвати аккаунт

Вхід

Уже зареєстровані? Увійдіть тут.

Вхід зараз
  • Зараз на сторінці   0 користувачів

    • Ні користувачів, які переглядиють цю сторінку
×
×
  • Створити...

Important Information

На нашому сайті використовуються файли cookie і відбувається обробка деяких персональних даних користувачів, щоб поліпшити користувальницький інтерфейс. Щоб дізнатися для чого і які персональні дані ми обробляємо перейдіть за посиланням . Якщо Ви натиснете «Я даю згоду», це означає, що Ви розумієте і приймаєте всі умови, зазначені в цьому Повідомленні про конфіденційність.