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

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

alexxxus
 Share

Recommended Posts

Sammy95 Rising Star

Sammy95

Опубліковано:
Опубліковано:

UncleAndy: со всем сказанным согласен, а проблемы я вижу только косвенные:

0. Сложность обновлений при изменении индексов. Т.е., например, если окажется, что несколько индексов можно существенно улучшить, добавив в них поля (или изменив их порядок), или поменяв порядок сортировки, то надо будет в upgrade.php дописать логику по удалению неправильного индекса. Хотя тут, наверное, можно просто удалять все индексы и заменять их своими при каждом апгрейде - основная масса пользователей своих индексов не делает.

1. Если у большинства владельцев магазинов в большинстве случаев всё будет работать нормально, то дамп большой БД мы вообще никогда не получим :)

2. Имея на руках дамп, можно будет ещё и сами запросы оптимизировать. Без него как-то сложновато.

А в остальном я не против, у меня в любом случае база маленькая и всё летает :lol:

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

UncleAndy Community Regular

UncleAndy

Опубліковано:
Опубліковано:

А в остальном я не против, у меня в любом случае база маленькая и всё летает :lol:

По любому я сначала открою соответствующую тему в ветке разработки.

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

Alexa Community Regular

Alexa

Опубліковано:
Опубліковано:

Помогите, плз, разобраться с slow.log на Денвере.

Т.к. тормозит жутко именно на денвере (кол-во товара и категорий меньше чем по-дефолту), а на хостинге летает (тьфу-тьфу).

В slow.log к примеру есть такие записи:

1)SELECT * FROM oc_product_option_value WHERE product_option_id = '283' ORDER BY sort_order;
# User@Host: opencart[opencart] @ localhost [127.0.0.1]
# Query_time: 0.015625  Lock_time: 0.000000 Rows_sent: 2  Rows_examined: 6
SET timestamp=1303756399;

2)SELECT * FROM oc_information i LEFT JOIN oc_information_description id ON (i.information_id = id.information_id) LEFT JOIN oc_information_to_store i2s ON (i.information_id = i2s.information_id) WHERE id.language_id = '1' AND i2s.store_id = '0' AND i.status = '1' AND i.sort_order <> '-1' ORDER BY i.sort_order, LCASE(id.title) ASC;
# Time: 110425 22:33:22
# User@Host: opencart[opencart] @ localhost [127.0.0.1]
# Query_time: 0.000000  Lock_time: 0.000000 Rows_sent: 138  Rows_examined: 138
SET timestamp=1303756402;

3)SELECT * FROM oc_weight_class wc LEFT JOIN oc_weight_class_description wcd ON (wc.weight_class_id = wcd.weight_class_id) WHERE wcd.language_id = '1';
# User@Host: opencart[opencart] @ localhost [127.0.0.1]
# Query_time: 0.046875  Lock_time: 0.000000 Rows_sent: 2  Rows_examined: 4
SET timestamp=1303756402;
По 1) в phpMyAdmin открываю таблицу oc_product_option_value - Структура - и ставлю галку для индексации в поле "product_option_id".

А по 2) и 3) варианту - не пойму, какое именно поле и в какой табл. нужно индексировать...?

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

UncleAndy Community Regular

UncleAndy

Опубліковано:
Опубліковано: 

# Query_time: 0.015625  Lock_time: 0.000000 Rows_sent: 2  Rows_examined: 6
# Query_time: 0.000000  Lock_time: 0.000000 Rows_sent: 138  Rows_examined: 138
# Query_time: 0.046875  Lock_time: 0.000000 Rows_sent: 2  Rows_examined: 4
По 1) в phpMyAdmin открываю таблицу oc_product_option_value - Структура - и ставлю галку для индексации в поле "product_option_id".

А по 2) и 3) варианту - не пойму, какое именно поле и в какой табл. нужно индексировать...?

Тут-же везде время исполнения запросов - сотые доли секунды. Или для вас это тоже медленно? :)

Думаю, торможения не из-за запросов. Или по крайней мере, из-за других запросов.

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

alexxxus Enthusiast

alexxxus

Опубліковано:
  • Автор
Опубліковано:

...Тогда уже и не знаю в чем причина тормозов именно на денвере....:(

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

выбор по языку (если только один язык, нет смысла делать выборку)

выбор по мультимагазинам (у меня только один)

выбор по дате

выбор по дискаунтам

выбор по статусу (если не отключаете товары, чтобы не показывались)

выбор ненужных опций товара

......

.....

и т.д.

Теперь магаз на 45000 продуктов летает как ошпаренный.

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

  • 2 months later...
RGB Grand Master

RGB

Опубліковано:
Опубліковано:

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

выбор по языку (если только один язык, нет смысла делать выборку)

выбор по мультимагазинам (у меня только один)

выбор по дате

выбор по дискаунтам

выбор по статусу (если не отключаете товары, чтобы не показывались)

выбор ненужных опций товара

......

.....

и т.д.

Теперь магаз на 45000 продуктов летает как ошпаренный.

Думаю не я один был бы вам очень благодарен за чуть более подробное описание, где конкретно и что вы повырезали?

Насколько я понимаю, это вы всю папочку \catalog\model\ перелопатили? Если вы не хотите тратить время на пояснения, может есть смысл залить где-то ее? С указанием вашей базовой версии, благо в старых версия (до RC) изменений не много и их реально провести собственноручно.

Спасибо вам заранее.

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

  • 5 weeks later...
Superbo Newbie

Superbo

Опубліковано:
Опубліковано:

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

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

  • 1 month later...
SaSS Collaborator

SaSS

Опубліковано:
Опубліковано:

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

выбор по языку (если только один язык, нет смысла делать выборку)

выбор по мультимагазинам (у меня только один)

выбор по дате

выбор по дискаунтам

выбор по статусу (если не отключаете товары, чтобы не показывались)

выбор ненужных опций товара

......

.....

и т.д.

Теперь магаз на 45000 продуктов летает как ошпаренный.

присоединюсь к вопросу xrgb

Думаю не я один был бы вам очень благодарен за чуть более подробное описание, где конкретно и что вы повырезали?

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

  • 1 month later...
alexxxus Enthusiast

alexxxus

Опубліковано:
  • Автор
Опубліковано:

Пример функции с сокращенной выборкой. Закомментирован обычный запрос, т.е. то, что было

catalog\model\catalog\product.php

public function getProducts() {

//$query = $this->db->query("SELECT DISTINCT *, pd.name AS name, p.image, m.name AS manufacturer, ss.name AS stock, wcd.unit AS weight_class FROM " . DB_PREFIX . "product p LEFT JOIN " . DB_PREFIX . "product_description pd ON (p.product_id = pd.product_id) LEFT JOIN " . DB_PREFIX . "product_to_store p2s ON (p.product_id = p2s.product_id) LEFT JOIN " . DB_PREFIX . "manufacturer m ON (p.manufacturer_id = m.manufacturer_id) LEFT JOIN " . DB_PREFIX . "stock_status ss ON (p.stock_status_id = ss.stock_status_id) LEFT JOIN " . DB_PREFIX . "weight_class_description wcd ON (p.weight_class_id = wcd.weight_class_id) WHERE pd.language_id = '" . (int)$this->config->get('config_language_id') . "' AND p2s.store_id = '" . (int)$this->config->get('config_store_id') . "' AND wcd.language_id = '" . (int)$this->config->get('config_language_id') . "' AND ss.language_id = '" . (int)$this->config->get('config_language_id') . "' AND p.date_available <= NOW() AND p.status = '1'");

$query = $this->db->query("SELECT DISTINCT *, pd.name AS name, p.image, m.name AS manufacturer FROM " . DB_PREFIX . "product p LEFT JOIN " . DB_PREFIX . "product_description pd ON (p.product_id = pd.product_id) LEFT JOIN " . DB_PREFIX . "manufacturer m ON (p.manufacturer_id = m.manufacturer_id)");

return $query->rows;

}

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

SaSS Collaborator

SaSS

Опубліковано:
Опубліковано: (змінено)

попытался сделать у себя по аналогии (ocStore 1.0.1)

удалил отмеченное красным

еще удалил то, что зеленым, но сайт перестал работать после этого

ругался на строку с $this->data['reward']

в catalog/controller/product/product.php

Заработал после того как ее закомментировал

Сейчас вреде работает, тестирую, что еще удалить можно? и не удалил ли я чего лишнего? )

$query = $this->db->query("SELECT DISTINCT *, pd.name AS name, p.image, m.name AS manufacturer, (SELECT price FROM " . DB_PREFIX . "product_discount pd2 WHERE pd2.product_id = p.product_id AND pd2.customer_group_id = '" . (int)$customer_group_id . "' AND pd2.quantity = '1' AND ((pd2.date_start = '0000-00-00' OR pd2.date_start < NOW()) AND (pd2.date_end = '0000-00-00' OR pd2.date_end > NOW())) ORDER BY pd2.priority ASC, pd2.price ASC LIMIT 1) AS discount, (SELECT price FROM " . DB_PREFIX . "product_special ps WHERE ps.product_id = p.product_id AND ps.customer_group_id = '" . (int)$customer_group_id . "' AND ((ps.date_start = '0000-00-00' OR ps.date_start < NOW()) AND (ps.date_end = '0000-00-00' OR ps.date_end > NOW())) ORDER BY ps.priority ASC, ps.price ASC LIMIT 1) AS special, (SELECT points FROM " . DB_PREFIX . "product_reward pr WHERE pr.product_id = p.product_id AND customer_group_id = '" . (int)$customer_group_id . "') AS reward, (SELECT ss.name FROM " . DB_PREFIX . "stock_status ss WHERE ss.stock_status_id = p.stock_status_id AND ss.language_id = '" . (int)$this->config->get('config_language_id') . "') AS stock_status, (SELECT wcd.unit FROM " . DB_PREFIX . "weight_class_description wcd WHERE p.weight_class_id = wcd.weight_class_id AND wcd.language_id = '" . (int)$this->config->get('config_language_id') . "') AS weight_class, (SELECT lcd.unit FROM " . DB_PREFIX . "length_class_description lcd WHERE p.length_class_id = lcd.length_class_id AND lcd.language_id = '" . (int)$this->config->get('config_language_id') . "') AS length_class, (SELECT AVG(rating) AS total FROM " . DB_PREFIX . "review r1 WHERE r1.product_id = p.product_id AND r1.status = '1' GROUP BY r1.product_id) AS rating, (SELECT COUNT(*) AS total FROM " . DB_PREFIX . "review r2 WHERE r2.product_id = p.product_id AND r2.status = '1' GROUP BY r2.product_id) AS reviews FROM " . DB_PREFIX . "product p LEFT JOIN " . DB_PREFIX . "product_description pd ON (p.product_id = pd.product_id) LEFT JOIN " . DB_PREFIX . "product_to_store p2s ON (p.product_id = p2s.product_id) LEFT JOIN " . DB_PREFIX . "manufacturer m ON (p.manufacturer_id = m.manufacturer_id) WHERE p.product_id = '" . (int)$product_id . "' AND pd.language_id = '" . (int)$this->config->get('config_language_id') . "' AND p.status = '1' AND p.date_available <= NOW() AND p2s.store_id = '" . (int)$this->config->get('config_store_id') . "'");

Змінено користувачем SaSS
Надіслати
Поділитися на інших сайтах

alexxxus Enthusiast

alexxxus

Опубліковано:
  • Автор
Опубліковано:

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

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

  • 3 months later...
Deus Explorer

Deus

Опубліковано:
Опубліковано:

Добрый день, никто не сталкивался с проблемой подтормаживания сайта не в категориях , а при переходе на страничку товара? После описанных в посте манипуляций навигация по сайту стала заметно быстрей, но переход к товару все равно осуществляется очень долго (порядка 7-8 секунд), на сайте порядка 6000 товаров. OC 1.5.1.3, сайт под сполером

http://deusstore.com/

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

Yesvik Veteran

Yesvik

Опубліковано:
Опубліковано:

Лучше конечно не использовать вывод рандомных товаров, но если очень надо - почитай про один из вариантов решения проблемы https://opencartforum.com/topic/4726-%D0%BC%D0%BE%D0%B4%D1%83%D0%BB%D1%8C-%D1%81%D0%BB%D1%83%D1%87%D0%B0%D0%B9%D0%BD%D1%8B%D0%B5-%D1%82%D0%BE%D0%B2%D0%B0%D1%80%D1%8B-oc15-ocstore-101/page__p__30871#entry30871

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

Blakkky Rookie

Blakkky

Опубліковано:
Опубліковано:

Поделюсь тем, что я делал для оптимизации (в дебрях форума есть diff на OC 1.4.9.x с этими изменениями):

1. все запросы, где участвуют store_id и language_id переписал по принципу:

select .... from product_description pd on(pd.product_id = p.product_id and pd.language_id = " . (int)$this->config->get('config_language_id') . ") ...

т.е. из where убрал проверки на язык и магазин, и перенес их в on-условие join-ов

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

2. на все поля вида xxx_id проставил индексы, если данное поле не входит в составные индексы (визуально смотрел в phpMyAdmin);

3. на поля из order (сортировок) из запросов навесил индексы (искал их просто поиском по коду);

4. Везде по коду заменил в запросах NOW() на вызов php-шной date( 'Y-m-d' ) / date( 'Y-m-d H:i:s' ) (в зависимости от логики запроса). Дает профит при правильной настройке кеширования запросов в mySQL, т.к. запросы с now() принципиально не кешируются;

5. подправил прочтение дерева каталога (см diff), вместо загрузки поэлементно всего дерева сделал выгрузку всей структуры одним запросом в кеш (сделал в кеше categories.0 вида self::$precategories[ id ] => $row) и подправил getCategory(...) на забор строчки не из базы, а из этого массива;

6. такой же трюк проделал в модуле seo_url.php, вынув все алиасы махом в кеш, сведя сотни запросов на странице (за каждим УРЛом в базу) к одному;

		private static $urls = null;
		private function load() {
				$urls = $this->db->query( "SELECT * FROM " . DB_PREFIX . "url_alias" );
				if ( $urls->num_rows > 0 ) {
						foreach ( $urls->rows as $url ) {
								self::$urls[ 'by_query' ][ $url[ 'query' ] ] = $url;
						}
				}
		}
		private function getByQuery( $query ) {
				if ( self::$urls == null ) {
						$this->load();
				}
				if ( isset( self::$urls[ 'by_query' ][ $query ] ) ) {
						$count = 1;
						$data = self::$urls[ 'by_query' ][ $query ];
				} else {
						$count = 0;
						$data = null;
				}
				$r = new stdClass();
				$r->row = $data;
				$r->num_rows = $count;
				return $r;
		}
......

Итог: на базе в 400 узлов каталога и 2000 позиций, с выключенным (!!!) кешем ($this->cache->delete('*') в индекс) c 800-1000 мс до 150-200 мс разогнались.

Если у кого есть база под OC 1.4.9 - 1.5 с сотнями тысяч - миллионами товаров/узлов каталога, выложите ее, если не сложно, было бы интерсно доправить

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

crigon Newbie

crigon

Опубліковано:
Опубліковано:

6. такой же трюк проделал в модуле seo_url.php, вынув все алиасы махом в кеш, сведя сотни запросов на странице (за каждим УРЛом в базу) к одному;

Существует ли такая проблема в seo_pro.php?
Надіслати
Поділитися на інших сайтах

  • 1 month later...
alch Rookie

alch

Опубліковано:
Опубліковано: (змінено)

Тоже столкнулся с медленной работой базы. в базе 10645 категорий. Пока тестирую работу без товаров.

После того как убрал getTotalProducts из hader.php стало лучше, но все равно плохо.

Execution Time: 3.425153 sec

В записи slow.log нашел.

# Query_time: 2.608207 Lock_time: 0.005001 Rows_sent: 10645 Rows_examined: 53225

SET timestamp=1334065097;

SELECT * FROM kybcategory c LEFT JOIN category_description cd ON (c.category_id = cd.category_id) LEFT JOIN category_to_store c2s ON (c.category_id = c2s.category_id) ORDER BY c.parent_id, c.sort_order, cd.name;

Как исправить данные проблемы.

И еще один момент в админке нереально зайти во вкладку "Товары". очень долго грузиться, тоже не нормальный симптом.

Может ли на скорость работы влиять то что при нумерации категорий используются номера от 1 до 50000, иногда с большими разрывами?

И вообще, вопрос к спецам, реальна нормальная работа магазина с 12000 категорий и таким же количеством товара ?

P.S. тестировал на Denwer. перенес на хостинг, заработало!!! Execution Time: 0.565078 sec

Хотя проблема со входом в товары в админке осталась. Что интересно. В Категории заходит без проблем, а в товары жжжжутко тормозит.

Змінено користувачем alch
Надіслати
Поділитися на інших сайтах

l.slava Enthusiast

l.slava

Опубліковано:
Опубліковано:

Тоже столкнулся с медленной работой базы. в базе 10645 категорий. Пока тестирую работу без товаров.

После того как убрал getTotalProducts из hader.php стало лучше, но все равно плохо.

Execution Time: 3.425153 sec

В записи slow.log нашел.

# Query_time: 2.608207 Lock_time: 0.005001 Rows_sent: 10645 Rows_examined: 53225

SET timestamp=1334065097;

SELECT * FROM kybcategory c LEFT JOIN category_description cd ON (c.category_id = cd.category_id) LEFT JOIN category_to_store c2s ON (c.category_id = c2s.category_id) ORDER BY c.parent_id, c.sort_order, cd.name;

Как исправить данные проблемы.

И еще один момент в админке нереально зайти во вкладку "Товары". очень долго грузиться, тоже не нормальный симптом.

Может ли на скорость работы влиять то что при нумерации категорий используются номера от 1 до 50000, иногда с большими разрывами?

И вообще, вопрос к спецам, реальна нормальная работа магазина с 12000 категорий и таким же количеством товара ?

P.S. тестировал на Denwer. перенес на хостинг, заработало!!! Execution Time: 0.565078 sec

Хотя проблема со входом в товары в админке осталась. Что интересно. В Категории заходит без проблем, а в товары жжжжутко тормозит.

Возможно это поможет: нужно немного оптимизировать ORDER BY, то же как раз этим занимаюсь тестирую сейчас запросы с

STRAIGHT_JOIN.

В магазине 81 тыс. товаров.

Да, еще я отключил вообще updateViewed 

//$this->db->query("UPDATE " . DB_PREFIX . "product SET viewed = viewed + 1 WHERE product_id = '" . (int)$product_id . "'");
это минус 1 запрос к базе.

Так как это статистика по большому счету никому не нужна.

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

freelancer Grand Master

freelancer

Опубліковано:
Опубліковано:

Хотя проблема со входом в товары в админке осталась. Что интересно. В Категории заходит без проблем, а в товары жжжжутко тормозит.

версия движка?

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

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

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

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

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

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

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

Вхід

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

Вхід зараз
 Share
Перейти до списку тем

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

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

Покупцям

Розробникам

Корисна інформація

Останні розширення

×
×
  • Створити...

Important Information

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

  Я даю згоду