Sammy95 Опубліковано: 22 квітня 2011 Share Опубліковано: 22 квітня 2011 UncleAndy: со всем сказанным согласен, а проблемы я вижу только косвенные: 0. Сложность обновлений при изменении индексов. Т.е., например, если окажется, что несколько индексов можно существенно улучшить, добавив в них поля (или изменив их порядок), или поменяв порядок сортировки, то надо будет в upgrade.php дописать логику по удалению неправильного индекса. Хотя тут, наверное, можно просто удалять все индексы и заменять их своими при каждом апгрейде - основная масса пользователей своих индексов не делает. 1. Если у большинства владельцев магазинов в большинстве случаев всё будет работать нормально, то дамп большой БД мы вообще никогда не получим :) 2. Имея на руках дамп, можно будет ещё и сами запросы оптимизировать. Без него как-то сложновато. А в остальном я не против, у меня в любом случае база маленькая и всё летает :lol: Надіслати Поділитися на інших сайтах More sharing options...
UncleAndy Опубліковано: 22 квітня 2011 Share Опубліковано: 22 квітня 2011 А в остальном я не против, у меня в любом случае база маленькая и всё летает :lol: По любому я сначала открою соответствующую тему в ветке разработки. Надіслати Поділитися на інших сайтах More sharing options...
alexxxus Опубліковано: 22 квітня 2011 Автор Share Опубліковано: 22 квітня 2011 Вот Ководство для понимания, как раз наш случай http://www.mysql.ru/docs/man/MySQL_indexes.html Надіслати Поділитися на інших сайтах More sharing options...
Alexa Опубліковано: 25 квітня 2011 Share Опубліковано: 25 квітня 2011 Помогите, плз, разобраться с 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) варианту - не пойму, какое именно поле и в какой табл. нужно индексировать...? Надіслати Поділитися на інших сайтах More sharing options...
UncleAndy Опубліковано: 26 квітня 2011 Share Опубліковано: 26 квітня 2011 # 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) варианту - не пойму, какое именно поле и в какой табл. нужно индексировать...? Тут-же везде время исполнения запросов - сотые доли секунды. Или для вас это тоже медленно? :) Думаю, торможения не из-за запросов. Или по крайней мере, из-за других запросов. Надіслати Поділитися на інших сайтах More sharing options...
Alexa Опубліковано: 26 квітня 2011 Share Опубліковано: 26 квітня 2011 ...Тогда уже и не знаю в чем причина тормозов именно на денвере....:( Надіслати Поділитися на інших сайтах More sharing options...
alexxxus Опубліковано: 3 травня 2011 Автор Share Опубліковано: 3 травня 2011 ...Тогда уже и не знаю в чем причина тормозов именно на денвере....:( Еще я у себя сократил вложенность выборки в селектах. А именно убрал то, что не используется в моем магазе: выбор по языку (если только один язык, нет смысла делать выборку) выбор по мультимагазинам (у меня только один) выбор по дате выбор по дискаунтам выбор по статусу (если не отключаете товары, чтобы не показывались) выбор ненужных опций товара ...... ..... и т.д. Теперь магаз на 45000 продуктов летает как ошпаренный. 1 Надіслати Поділитися на інших сайтах More sharing options...
RGB Опубліковано: 7 липня 2011 Share Опубліковано: 7 липня 2011 Еще я у себя сократил вложенность выборки в селектах. А именно убрал то, что не используется в моем магазе: выбор по языку (если только один язык, нет смысла делать выборку) выбор по мультимагазинам (у меня только один) выбор по дате выбор по дискаунтам выбор по статусу (если не отключаете товары, чтобы не показывались) выбор ненужных опций товара ...... ..... и т.д. Теперь магаз на 45000 продуктов летает как ошпаренный. Думаю не я один был бы вам очень благодарен за чуть более подробное описание, где конкретно и что вы повырезали? Насколько я понимаю, это вы всю папочку \catalog\model\ перелопатили? Если вы не хотите тратить время на пояснения, может есть смысл залить где-то ее? С указанием вашей базовой версии, благо в старых версия (до RC) изменений не много и их реально провести собственноручно. Спасибо вам заранее. 1 Надіслати Поділитися на інших сайтах More sharing options... 5 weeks later... Superbo Опубліковано: 7 серпня 2011 Share Опубліковано: 7 серпня 2011 Недавно наткнулся на сервис cloud-db,net и решил те проблемы про которые говорят что невозможно загрузил базу и получил маштабируемость а производительность увеличилась на порядок Надіслати Поділитися на інших сайтах More sharing options... Yesvik Опубліковано: 7 серпня 2011 Share Опубліковано: 7 серпня 2011 У меня по прежнему не работает кнопка "Жалоба", пишет [#10136] У вас не достаточно прав для отправки жалобы. Надіслати Поділитися на інших сайтах More sharing options... 1 month later... SaSS Опубліковано: 25 вересня 2011 Share Опубліковано: 25 вересня 2011 Еще я у себя сократил вложенность выборки в селектах. А именно убрал то, что не используется в моем магазе: выбор по языку (если только один язык, нет смысла делать выборку) выбор по мультимагазинам (у меня только один) выбор по дате выбор по дискаунтам выбор по статусу (если не отключаете товары, чтобы не показывались) выбор ненужных опций товара ...... ..... и т.д. Теперь магаз на 45000 продуктов летает как ошпаренный. присоединюсь к вопросу xrgb Думаю не я один был бы вам очень благодарен за чуть более подробное описание, где конкретно и что вы повырезали? Надіслати Поділитися на інших сайтах More sharing options... 1 month later... alexxxus Опубліковано: 7 листопада 2011 Автор Share Опубліковано: 7 листопада 2011 Пример функции с сокращенной выборкой. Закомментирован обычный запрос, т.е. то, что было 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; } Надіслати Поділитися на інших сайтах More sharing options... SaSS Опубліковано: 7 листопада 2011 Share Опубліковано: 7 листопада 2011 мдя... как китайская грамота ( единственное, о чем догадываюсь, это пример не из версии ocstore 1.0.1 Там этот запрос с 2 раза длиннее Надіслати Поділитися на інших сайтах More sharing options... SaSS Опубліковано: 7 листопада 2011 Share Опубліковано: 7 листопада 2011 (змінено) попытался сделать у себя по аналогии (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') . "'"); Змінено 7 листопада 2011 користувачем SaSS Надіслати Поділитися на інших сайтах More sharing options... alexxxus Опубліковано: 7 листопада 2011 Автор Share Опубліковано: 7 листопада 2011 Я ж говорил - все сугубо индивидуально под каждую установку и под каждый магаз. Пример дал для понимания принципа, а не для слепого копирования. Надіслати Поділитися на інших сайтах More sharing options... 3 months later... Deus Опубліковано: 12 лютого 2012 Share Опубліковано: 12 лютого 2012 Добрый день, никто не сталкивался с проблемой подтормаживания сайта не в категориях , а при переходе на страничку товара? После описанных в посте манипуляций навигация по сайту стала заметно быстрей, но переход к товару все равно осуществляется очень долго (порядка 7-8 секунд), на сайте порядка 6000 товаров. OC 1.5.1.3, сайт под сполером http://deusstore.com/ Надіслати Поділитися на інших сайтах More sharing options... Yesvik Опубліковано: 12 лютого 2012 Share Опубліковано: 12 лютого 2012 Вероятнее всего тормозит модуль Случайные товары. Надіслати Поділитися на інших сайтах More sharing options... Deus Опубліковано: 14 лютого 2012 Share Опубліковано: 14 лютого 2012 Да, спасибо, так и есть. Я и не думал, что с этим может быть связано, почти в 3 раза быстрей стала загрузка. Надіслати Поділитися на інших сайтах More sharing options... Yesvik Опубліковано: 19 лютого 2012 Share Опубліковано: 19 лютого 2012 Лучше конечно не использовать вывод рандомных товаров, но если очень надо - почитай про один из вариантов решения проблемы 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 Надіслати Поділитися на інших сайтах More sharing options... Blakkky Опубліковано: 20 лютого 2012 Share Опубліковано: 20 лютого 2012 Поделюсь тем, что я делал для оптимизации (в дебрях форума есть 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 с сотнями тысяч - миллионами товаров/узлов каталога, выложите ее, если не сложно, было бы интерсно доправить 2 Надіслати Поділитися на інших сайтах More sharing options... freelancer Опубліковано: 21 лютого 2012 Share Опубліковано: 21 лютого 2012 Поделюсь тем, что я делал для оптимизации (в дебрях форума есть diff на OC 1.4.9.x с этими изменениями): ... очень интересно Надіслати Поділитися на інших сайтах More sharing options... crigon Опубліковано: 21 лютого 2012 Share Опубліковано: 21 лютого 2012 6. такой же трюк проделал в модуле seo_url.php, вынув все алиасы махом в кеш, сведя сотни запросов на странице (за каждим УРЛом в базу) к одному;Существует ли такая проблема в seo_pro.php? Надіслати Поділитися на інших сайтах More sharing options... 1 month later... alch Опубліковано: 10 квітня 2012 Share Опубліковано: 10 квітня 2012 (змінено) Тоже столкнулся с медленной работой базы. в базе 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 Хотя проблема со входом в товары в админке осталась. Что интересно. В Категории заходит без проблем, а в товары жжжжутко тормозит. Змінено 10 квітня 2012 користувачем alch Надіслати Поділитися на інших сайтах More sharing options... l.slava Опубліковано: 10 квітня 2012 Share Опубліковано: 10 квітня 2012 Тоже столкнулся с медленной работой базы. в базе 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 запрос к базе.Так как это статистика по большому счету никому не нужна. Надіслати Поділитися на інших сайтах More sharing options... freelancer Опубліковано: 10 квітня 2012 Share Опубліковано: 10 квітня 2012 Хотя проблема со входом в товары в админке осталась. Что интересно. В Категории заходит без проблем, а в товары жжжжутко тормозит.версия движка?при редактировании товара категории все сразу грузит. у меня было решение, найду выложу Надіслати Поділитися на інших сайтах More sharing options... Назад 1 2 3 4 Вперед Сторінка 2 з 4 Створіть аккаунт або увійдіть для коментування Ви повинні бути користувачем, щоб залишити коментар Створити обліковий запис Зареєструйтеся для отримання облікового запису. Це просто! Зареєструвати аккаунт Вхід Уже зареєстровані? Увійдіть тут. Вхід зараз Share More sharing options... Передплатники 0 Перейти до списку тем Зараз на сторінці 0 користувачів Ні користувачів, які переглядиють цю сторінку Последние темы Последние дополнения Последние новости Вся активність Головна Підтримка та відповіді на запитання. Встановлення, оновлення, налаштування Тормозит ужасно [решено] Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення SP Telegram повідомлення FREE Автор: spectre Відключити порожні категорії Автор: spectre SEO Автор тексту категорії / фільтра / блогу з датою оновлення контенту + мікророзмітка Автор: radaevich Промо банери в категоріях товарів Автор: IHOR1989 Trend - адаптивний універсальний шаблон Автор: DSV × Уже зареєстровані? Ввійти Реєстрація Ваші замовлення Назад Придбані модулі та шаблони Ваші рахунки Лист очікувань Альтернативні контакти Форум Новини ocStore Назад Офіційний сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Завантажити ocStore Документація Історія версій ocStore Блоги Модулі Шаблони Назад Безкоштовні шаблони Платні шаблони Де купувати модулі? Послуги FAQ OpenCart.Pro Назад Демо Купити Порівняння × Створити... Important Information На нашому сайті використовуються файли cookie і відбувається обробка деяких персональних даних користувачів, щоб поліпшити користувальницький інтерфейс. Щоб дізнатися для чого і які персональні дані ми обробляємо перейдіть за посиланням . Якщо Ви натиснете «Я даю згоду», це означає, що Ви розумієте і приймаєте всі умови, зазначені в цьому Повідомленні про конфіденційність. Я даю згоду
Superbo Опубліковано: 7 серпня 2011 Share Опубліковано: 7 серпня 2011 Недавно наткнулся на сервис cloud-db,net и решил те проблемы про которые говорят что невозможно загрузил базу и получил маштабируемость а производительность увеличилась на порядок Надіслати Поділитися на інших сайтах More sharing options...
Yesvik Опубліковано: 7 серпня 2011 Share Опубліковано: 7 серпня 2011 У меня по прежнему не работает кнопка "Жалоба", пишет [#10136] У вас не достаточно прав для отправки жалобы. Надіслати Поділитися на інших сайтах More sharing options... 1 month later... SaSS Опубліковано: 25 вересня 2011 Share Опубліковано: 25 вересня 2011 Еще я у себя сократил вложенность выборки в селектах. А именно убрал то, что не используется в моем магазе: выбор по языку (если только один язык, нет смысла делать выборку) выбор по мультимагазинам (у меня только один) выбор по дате выбор по дискаунтам выбор по статусу (если не отключаете товары, чтобы не показывались) выбор ненужных опций товара ...... ..... и т.д. Теперь магаз на 45000 продуктов летает как ошпаренный. присоединюсь к вопросу xrgb Думаю не я один был бы вам очень благодарен за чуть более подробное описание, где конкретно и что вы повырезали? Надіслати Поділитися на інших сайтах More sharing options... 1 month later... alexxxus Опубліковано: 7 листопада 2011 Автор Share Опубліковано: 7 листопада 2011 Пример функции с сокращенной выборкой. Закомментирован обычный запрос, т.е. то, что было 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; } Надіслати Поділитися на інших сайтах More sharing options... SaSS Опубліковано: 7 листопада 2011 Share Опубліковано: 7 листопада 2011 мдя... как китайская грамота ( единственное, о чем догадываюсь, это пример не из версии ocstore 1.0.1 Там этот запрос с 2 раза длиннее Надіслати Поділитися на інших сайтах More sharing options... SaSS Опубліковано: 7 листопада 2011 Share Опубліковано: 7 листопада 2011 (змінено) попытался сделать у себя по аналогии (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') . "'"); Змінено 7 листопада 2011 користувачем SaSS Надіслати Поділитися на інших сайтах More sharing options... alexxxus Опубліковано: 7 листопада 2011 Автор Share Опубліковано: 7 листопада 2011 Я ж говорил - все сугубо индивидуально под каждую установку и под каждый магаз. Пример дал для понимания принципа, а не для слепого копирования. Надіслати Поділитися на інших сайтах More sharing options... 3 months later... Deus Опубліковано: 12 лютого 2012 Share Опубліковано: 12 лютого 2012 Добрый день, никто не сталкивался с проблемой подтормаживания сайта не в категориях , а при переходе на страничку товара? После описанных в посте манипуляций навигация по сайту стала заметно быстрей, но переход к товару все равно осуществляется очень долго (порядка 7-8 секунд), на сайте порядка 6000 товаров. OC 1.5.1.3, сайт под сполером http://deusstore.com/ Надіслати Поділитися на інших сайтах More sharing options... Yesvik Опубліковано: 12 лютого 2012 Share Опубліковано: 12 лютого 2012 Вероятнее всего тормозит модуль Случайные товары. Надіслати Поділитися на інших сайтах More sharing options... Deus Опубліковано: 14 лютого 2012 Share Опубліковано: 14 лютого 2012 Да, спасибо, так и есть. Я и не думал, что с этим может быть связано, почти в 3 раза быстрей стала загрузка. Надіслати Поділитися на інших сайтах More sharing options... Yesvik Опубліковано: 19 лютого 2012 Share Опубліковано: 19 лютого 2012 Лучше конечно не использовать вывод рандомных товаров, но если очень надо - почитай про один из вариантов решения проблемы 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 Надіслати Поділитися на інших сайтах More sharing options... Blakkky Опубліковано: 20 лютого 2012 Share Опубліковано: 20 лютого 2012 Поделюсь тем, что я делал для оптимизации (в дебрях форума есть 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 с сотнями тысяч - миллионами товаров/узлов каталога, выложите ее, если не сложно, было бы интерсно доправить 2 Надіслати Поділитися на інших сайтах More sharing options... freelancer Опубліковано: 21 лютого 2012 Share Опубліковано: 21 лютого 2012 Поделюсь тем, что я делал для оптимизации (в дебрях форума есть diff на OC 1.4.9.x с этими изменениями): ... очень интересно Надіслати Поділитися на інших сайтах More sharing options... crigon Опубліковано: 21 лютого 2012 Share Опубліковано: 21 лютого 2012 6. такой же трюк проделал в модуле seo_url.php, вынув все алиасы махом в кеш, сведя сотни запросов на странице (за каждим УРЛом в базу) к одному;Существует ли такая проблема в seo_pro.php? Надіслати Поділитися на інших сайтах More sharing options... 1 month later... alch Опубліковано: 10 квітня 2012 Share Опубліковано: 10 квітня 2012 (змінено) Тоже столкнулся с медленной работой базы. в базе 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 Хотя проблема со входом в товары в админке осталась. Что интересно. В Категории заходит без проблем, а в товары жжжжутко тормозит. Змінено 10 квітня 2012 користувачем alch Надіслати Поділитися на інших сайтах More sharing options... l.slava Опубліковано: 10 квітня 2012 Share Опубліковано: 10 квітня 2012 Тоже столкнулся с медленной работой базы. в базе 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 запрос к базе.Так как это статистика по большому счету никому не нужна. Надіслати Поділитися на інших сайтах More sharing options... freelancer Опубліковано: 10 квітня 2012 Share Опубліковано: 10 квітня 2012 Хотя проблема со входом в товары в админке осталась. Что интересно. В Категории заходит без проблем, а в товары жжжжутко тормозит.версия движка?при редактировании товара категории все сразу грузит. у меня было решение, найду выложу Надіслати Поділитися на інших сайтах More sharing options... Назад 1 2 3 4 Вперед Сторінка 2 з 4 Створіть аккаунт або увійдіть для коментування Ви повинні бути користувачем, щоб залишити коментар Створити обліковий запис Зареєструйтеся для отримання облікового запису. Це просто! Зареєструвати аккаунт Вхід Уже зареєстровані? Увійдіть тут. Вхід зараз Share More sharing options... Передплатники 0 Перейти до списку тем Зараз на сторінці 0 користувачів Ні користувачів, які переглядиють цю сторінку Последние темы Последние дополнения Последние новости Вся активність Головна Підтримка та відповіді на запитання. Встановлення, оновлення, налаштування Тормозит ужасно [решено] Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення SP Telegram повідомлення FREE Автор: spectre Відключити порожні категорії Автор: spectre SEO Автор тексту категорії / фільтра / блогу з датою оновлення контенту + мікророзмітка Автор: radaevich Промо банери в категоріях товарів Автор: IHOR1989 Trend - адаптивний універсальний шаблон Автор: DSV × Уже зареєстровані? Ввійти Реєстрація Ваші замовлення Назад Придбані модулі та шаблони Ваші рахунки Лист очікувань Альтернативні контакти Форум Новини ocStore Назад Офіційний сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Завантажити ocStore Документація Історія версій ocStore Блоги Модулі Шаблони Назад Безкоштовні шаблони Платні шаблони Де купувати модулі? Послуги FAQ OpenCart.Pro Назад Демо Купити Порівняння × Створити... Important Information На нашому сайті використовуються файли cookie і відбувається обробка деяких персональних даних користувачів, щоб поліпшити користувальницький інтерфейс. Щоб дізнатися для чого і які персональні дані ми обробляємо перейдіть за посиланням . Якщо Ви натиснете «Я даю згоду», це означає, що Ви розумієте і приймаєте всі умови, зазначені в цьому Повідомленні про конфіденційність. Я даю згоду
SaSS Опубліковано: 25 вересня 2011 Share Опубліковано: 25 вересня 2011 Еще я у себя сократил вложенность выборки в селектах. А именно убрал то, что не используется в моем магазе: выбор по языку (если только один язык, нет смысла делать выборку) выбор по мультимагазинам (у меня только один) выбор по дате выбор по дискаунтам выбор по статусу (если не отключаете товары, чтобы не показывались) выбор ненужных опций товара ...... ..... и т.д. Теперь магаз на 45000 продуктов летает как ошпаренный. присоединюсь к вопросу xrgb Думаю не я один был бы вам очень благодарен за чуть более подробное описание, где конкретно и что вы повырезали? Надіслати Поділитися на інших сайтах More sharing options...
alexxxus Опубліковано: 7 листопада 2011 Автор Share Опубліковано: 7 листопада 2011 Пример функции с сокращенной выборкой. Закомментирован обычный запрос, т.е. то, что было 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; } Надіслати Поділитися на інших сайтах More sharing options...
SaSS Опубліковано: 7 листопада 2011 Share Опубліковано: 7 листопада 2011 мдя... как китайская грамота ( единственное, о чем догадываюсь, это пример не из версии ocstore 1.0.1 Там этот запрос с 2 раза длиннее Надіслати Поділитися на інших сайтах More sharing options...
SaSS Опубліковано: 7 листопада 2011 Share Опубліковано: 7 листопада 2011 (змінено) попытался сделать у себя по аналогии (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') . "'"); Змінено 7 листопада 2011 користувачем SaSS Надіслати Поділитися на інших сайтах More sharing options...
alexxxus Опубліковано: 7 листопада 2011 Автор Share Опубліковано: 7 листопада 2011 Я ж говорил - все сугубо индивидуально под каждую установку и под каждый магаз. Пример дал для понимания принципа, а не для слепого копирования. Надіслати Поділитися на інших сайтах More sharing options...
Deus Опубліковано: 12 лютого 2012 Share Опубліковано: 12 лютого 2012 Добрый день, никто не сталкивался с проблемой подтормаживания сайта не в категориях , а при переходе на страничку товара? После описанных в посте манипуляций навигация по сайту стала заметно быстрей, но переход к товару все равно осуществляется очень долго (порядка 7-8 секунд), на сайте порядка 6000 товаров. OC 1.5.1.3, сайт под сполером http://deusstore.com/ Надіслати Поділитися на інших сайтах More sharing options...
Yesvik Опубліковано: 12 лютого 2012 Share Опубліковано: 12 лютого 2012 Вероятнее всего тормозит модуль Случайные товары. Надіслати Поділитися на інших сайтах More sharing options... Deus Опубліковано: 14 лютого 2012 Share Опубліковано: 14 лютого 2012 Да, спасибо, так и есть. Я и не думал, что с этим может быть связано, почти в 3 раза быстрей стала загрузка. Надіслати Поділитися на інших сайтах More sharing options... Yesvik Опубліковано: 19 лютого 2012 Share Опубліковано: 19 лютого 2012 Лучше конечно не использовать вывод рандомных товаров, но если очень надо - почитай про один из вариантов решения проблемы 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 Надіслати Поділитися на інших сайтах More sharing options... Blakkky Опубліковано: 20 лютого 2012 Share Опубліковано: 20 лютого 2012 Поделюсь тем, что я делал для оптимизации (в дебрях форума есть 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 с сотнями тысяч - миллионами товаров/узлов каталога, выложите ее, если не сложно, было бы интерсно доправить 2 Надіслати Поділитися на інших сайтах More sharing options... freelancer Опубліковано: 21 лютого 2012 Share Опубліковано: 21 лютого 2012 Поделюсь тем, что я делал для оптимизации (в дебрях форума есть diff на OC 1.4.9.x с этими изменениями): ... очень интересно Надіслати Поділитися на інших сайтах More sharing options... crigon Опубліковано: 21 лютого 2012 Share Опубліковано: 21 лютого 2012 6. такой же трюк проделал в модуле seo_url.php, вынув все алиасы махом в кеш, сведя сотни запросов на странице (за каждим УРЛом в базу) к одному;Существует ли такая проблема в seo_pro.php? Надіслати Поділитися на інших сайтах More sharing options... 1 month later... alch Опубліковано: 10 квітня 2012 Share Опубліковано: 10 квітня 2012 (змінено) Тоже столкнулся с медленной работой базы. в базе 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 Хотя проблема со входом в товары в админке осталась. Что интересно. В Категории заходит без проблем, а в товары жжжжутко тормозит. Змінено 10 квітня 2012 користувачем alch Надіслати Поділитися на інших сайтах More sharing options... l.slava Опубліковано: 10 квітня 2012 Share Опубліковано: 10 квітня 2012 Тоже столкнулся с медленной работой базы. в базе 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 запрос к базе.Так как это статистика по большому счету никому не нужна. Надіслати Поділитися на інших сайтах More sharing options... freelancer Опубліковано: 10 квітня 2012 Share Опубліковано: 10 квітня 2012 Хотя проблема со входом в товары в админке осталась. Что интересно. В Категории заходит без проблем, а в товары жжжжутко тормозит.версия движка?при редактировании товара категории все сразу грузит. у меня было решение, найду выложу Надіслати Поділитися на інших сайтах More sharing options... Назад 1 2 3 4 Вперед Сторінка 2 з 4 Створіть аккаунт або увійдіть для коментування Ви повинні бути користувачем, щоб залишити коментар Створити обліковий запис Зареєструйтеся для отримання облікового запису. Це просто! Зареєструвати аккаунт Вхід Уже зареєстровані? Увійдіть тут. Вхід зараз Share More sharing options... Передплатники 0 Перейти до списку тем Зараз на сторінці 0 користувачів Ні користувачів, які переглядиють цю сторінку Последние темы Последние дополнения Последние новости Вся активність Головна Підтримка та відповіді на запитання. Встановлення, оновлення, налаштування Тормозит ужасно [решено] Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення SP Telegram повідомлення FREE Автор: spectre Відключити порожні категорії Автор: spectre SEO Автор тексту категорії / фільтра / блогу з датою оновлення контенту + мікророзмітка Автор: radaevich Промо банери в категоріях товарів Автор: IHOR1989 Trend - адаптивний універсальний шаблон Автор: DSV
Deus Опубліковано: 14 лютого 2012 Share Опубліковано: 14 лютого 2012 Да, спасибо, так и есть. Я и не думал, что с этим может быть связано, почти в 3 раза быстрей стала загрузка. Надіслати Поділитися на інших сайтах More sharing options...
Yesvik Опубліковано: 19 лютого 2012 Share Опубліковано: 19 лютого 2012 Лучше конечно не использовать вывод рандомных товаров, но если очень надо - почитай про один из вариантов решения проблемы 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 Надіслати Поділитися на інших сайтах More sharing options... Blakkky Опубліковано: 20 лютого 2012 Share Опубліковано: 20 лютого 2012 Поделюсь тем, что я делал для оптимизации (в дебрях форума есть 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 с сотнями тысяч - миллионами товаров/узлов каталога, выложите ее, если не сложно, было бы интерсно доправить 2 Надіслати Поділитися на інших сайтах More sharing options... freelancer Опубліковано: 21 лютого 2012 Share Опубліковано: 21 лютого 2012 Поделюсь тем, что я делал для оптимизации (в дебрях форума есть diff на OC 1.4.9.x с этими изменениями): ... очень интересно Надіслати Поділитися на інших сайтах More sharing options... crigon Опубліковано: 21 лютого 2012 Share Опубліковано: 21 лютого 2012 6. такой же трюк проделал в модуле seo_url.php, вынув все алиасы махом в кеш, сведя сотни запросов на странице (за каждим УРЛом в базу) к одному;Существует ли такая проблема в seo_pro.php? Надіслати Поділитися на інших сайтах More sharing options... 1 month later... alch Опубліковано: 10 квітня 2012 Share Опубліковано: 10 квітня 2012 (змінено) Тоже столкнулся с медленной работой базы. в базе 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 Хотя проблема со входом в товары в админке осталась. Что интересно. В Категории заходит без проблем, а в товары жжжжутко тормозит. Змінено 10 квітня 2012 користувачем alch Надіслати Поділитися на інших сайтах More sharing options... l.slava Опубліковано: 10 квітня 2012 Share Опубліковано: 10 квітня 2012 Тоже столкнулся с медленной работой базы. в базе 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 запрос к базе.Так как это статистика по большому счету никому не нужна. Надіслати Поділитися на інших сайтах More sharing options... freelancer Опубліковано: 10 квітня 2012 Share Опубліковано: 10 квітня 2012 Хотя проблема со входом в товары в админке осталась. Что интересно. В Категории заходит без проблем, а в товары жжжжутко тормозит.версия движка?при редактировании товара категории все сразу грузит. у меня было решение, найду выложу Надіслати Поділитися на інших сайтах More sharing options... Назад 1 2 3 4 Вперед Сторінка 2 з 4 Створіть аккаунт або увійдіть для коментування Ви повинні бути користувачем, щоб залишити коментар Створити обліковий запис Зареєструйтеся для отримання облікового запису. Це просто! Зареєструвати аккаунт Вхід Уже зареєстровані? Увійдіть тут. Вхід зараз Share More sharing options... Передплатники 0 Перейти до списку тем Зараз на сторінці 0 користувачів Ні користувачів, які переглядиють цю сторінку Последние темы Последние дополнения Последние новости Вся активність Головна Підтримка та відповіді на запитання. Встановлення, оновлення, налаштування Тормозит ужасно [решено]
Blakkky Опубліковано: 20 лютого 2012 Share Опубліковано: 20 лютого 2012 Поделюсь тем, что я делал для оптимизации (в дебрях форума есть 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 с сотнями тысяч - миллионами товаров/узлов каталога, выложите ее, если не сложно, было бы интерсно доправить 2 Надіслати Поділитися на інших сайтах More sharing options...
freelancer Опубліковано: 21 лютого 2012 Share Опубліковано: 21 лютого 2012 Поделюсь тем, что я делал для оптимизации (в дебрях форума есть diff на OC 1.4.9.x с этими изменениями): ... очень интересно Надіслати Поділитися на інших сайтах More sharing options... crigon Опубліковано: 21 лютого 2012 Share Опубліковано: 21 лютого 2012 6. такой же трюк проделал в модуле seo_url.php, вынув все алиасы махом в кеш, сведя сотни запросов на странице (за каждим УРЛом в базу) к одному;Существует ли такая проблема в seo_pro.php? Надіслати Поділитися на інших сайтах More sharing options... 1 month later... alch Опубліковано: 10 квітня 2012 Share Опубліковано: 10 квітня 2012 (змінено) Тоже столкнулся с медленной работой базы. в базе 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 Хотя проблема со входом в товары в админке осталась. Что интересно. В Категории заходит без проблем, а в товары жжжжутко тормозит. Змінено 10 квітня 2012 користувачем alch Надіслати Поділитися на інших сайтах More sharing options... l.slava Опубліковано: 10 квітня 2012 Share Опубліковано: 10 квітня 2012 Тоже столкнулся с медленной работой базы. в базе 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 запрос к базе.Так как это статистика по большому счету никому не нужна. Надіслати Поділитися на інших сайтах More sharing options... freelancer Опубліковано: 10 квітня 2012 Share Опубліковано: 10 квітня 2012 Хотя проблема со входом в товары в админке осталась. Что интересно. В Категории заходит без проблем, а в товары жжжжутко тормозит.версия движка?при редактировании товара категории все сразу грузит. у меня было решение, найду выложу Надіслати Поділитися на інших сайтах More sharing options... Назад 1 2 3 4 Вперед Сторінка 2 з 4 Створіть аккаунт або увійдіть для коментування Ви повинні бути користувачем, щоб залишити коментар Створити обліковий запис Зареєструйтеся для отримання облікового запису. Це просто! Зареєструвати аккаунт Вхід Уже зареєстровані? Увійдіть тут. Вхід зараз Share More sharing options... Передплатники 0 Перейти до списку тем Зараз на сторінці 0 користувачів Ні користувачів, які переглядиють цю сторінку
crigon Опубліковано: 21 лютого 2012 Share Опубліковано: 21 лютого 2012 6. такой же трюк проделал в модуле seo_url.php, вынув все алиасы махом в кеш, сведя сотни запросов на странице (за каждим УРЛом в базу) к одному;Существует ли такая проблема в seo_pro.php? Надіслати Поділитися на інших сайтах More sharing options...
alch Опубліковано: 10 квітня 2012 Share Опубліковано: 10 квітня 2012 (змінено) Тоже столкнулся с медленной работой базы. в базе 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 Хотя проблема со входом в товары в админке осталась. Что интересно. В Категории заходит без проблем, а в товары жжжжутко тормозит. Змінено 10 квітня 2012 користувачем alch Надіслати Поділитися на інших сайтах More sharing options...
l.slava Опубліковано: 10 квітня 2012 Share Опубліковано: 10 квітня 2012 Тоже столкнулся с медленной работой базы. в базе 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 запрос к базе.Так как это статистика по большому счету никому не нужна. Надіслати Поділитися на інших сайтах More sharing options...
freelancer Опубліковано: 10 квітня 2012 Share Опубліковано: 10 квітня 2012 Хотя проблема со входом в товары в админке осталась. Что интересно. В Категории заходит без проблем, а в товары жжжжутко тормозит.версия движка?при редактировании товара категории все сразу грузит. у меня было решение, найду выложу Надіслати Поділитися на інших сайтах More sharing options... Назад 1 2 3 4 Вперед Сторінка 2 з 4 Створіть аккаунт або увійдіть для коментування Ви повинні бути користувачем, щоб залишити коментар Створити обліковий запис Зареєструйтеся для отримання облікового запису. Це просто! Зареєструвати аккаунт Вхід Уже зареєстровані? Увійдіть тут. Вхід зараз Share More sharing options... Передплатники 0
Recommended Posts