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 с сотнями тысяч - миллионами товаров/узлов каталога, выложите ее, если не сложно, было бы интерсно доправить

А в чем, собственно, "неправильность"? Код в нужную модель: // $table - имя таблицы, $field - имя поля, $fieldType - тим поля if ( !$this->config->get( 'my_patch_installed' ) ) { $r = $this->db->query( 'SHOW FIELDS FROM `' . DB_PREFIX . $table . '` WHERE `Field` = \'' . $field . '\'' ); if ( $r->num_rows == 0 ) { $this->db->query( 'ALTER TABLE `' DB_PREFIX . $table . '` ADD COLUMN `' . $field . '` ' . $fieldType . '' ); } $this->config->set( 'my_patch_installed', true ); } Ну идея, думаю, понятна. Если я ничего не путаю, весь конфиг OpenCart грузит в один запрос, так что тут "лишнего" ничего не будет. Если нет - проверку на установленность переменной конфига "my_patch_installed" убираем, чтоб лишний запрос в базу не гонять.

Ну для себя я так и делал, просто в подвал сайта ссыпал запросы, медленнее 0.01 сек и их explain-ы (в diff-е есть этот код) чтоб при отладке посмотреть, что к чему и подправить.Честно говоря, было огромное желание нормализовать базу по-человечески (в честности, избавиться от вложенных запросов для выбора рейтинга) и дописать целую кучу BaseТипНадстройкиController-ов (BaseShipping, BasePayment, BaseModuleController и т.д.) чтоб уменьшить копипаст кода при создании модулей, типов доставок и т.д. Остановило то, что это все будет абсолютно не совместимо с opencart-ом и поддерживать это будет намного труднее.

В базе у меня порядка 2300 товаров и 210 категорий, включен СЕО, поставлен модуль "deadcow seo", на главной показывается 10 последних новинок и 30 "лучших товаров". 75 запросов - это похоже на работу кеша резалтсетов (mysql_cached подключен как драйвер базы). В моем патче я запросы мерюю непосредственно в методе DB->query();, т.е. до решения о том, где данные, в кеше или в базе. Реально запросов на много больше, и вот почему: Главная страница, это: - Загрузить конфиг, настройки модулей и т.д. - 10-30 запросов в базу; - Загрузить 30 категорий - 30-50 запросов в базу; - Загрузить 10 позиций для "новинок" - 10 запросов в базу за загрузку + обновить кол-во просмотров (еще 10 запросов); - Загрузить 30 позиций (по модулю "Последние") - 30 запросов в базу за загрузку + обновить кол-во просмотров (еще 30 запросов); - Загрузить 10 статей - 3-5 запросов; - Загрузить ссылки для SEF/ЧПУ - по 2 запроса на элемент страницы (т.е. (30 категорий + 40 позиций товара + 10 статей + 210 категорий, чтоб полный путь в ЧПУ построить) * 2 итого ~ 400 запросов. Без ЧПУ выходит порядка 150-200 запросов в базу, с ЧПУ - к 600 подбирается. И это совсем скромные оценки :) У меня сейчас стабильно 0.15 - 0.2 сек генерация любой страницы у магазина. Если есть желание, готов помочь прикрутить патч к Вашему магазину.

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

Времени пока на анализ текстов нет, по-позже обязательно отпишусь.А касательно этой ошибки - по стандарту xhtml1 атрибута tab нету у тега a, но он нужен jQuery-скриптам, чтобы работать с вкладками. Вариантов два: 1. забить на валидацию 2. использовать вместо tab, скажем, rel или, что лучше, href и переписать jQuery-скрипты под использование значения href вместо tab. вот, например, подправленный под использование href-ов стандартный рисователь таб-контрола из базовой темы OpenCart-а из моего магазина. Файл /catalog/view/javascript/jquery/tab.js (только не забудьте, что перед его изменением надо во всех шаблонах, где есть такие же кантролы переписать tab-ы на href-ы, т.е. вместо <a tab="#some">...</a>, ставим <a href="#some">...</a>): $.tabs = function( selector, start ) { $( selector ).each( function( i, element ) { $( element ).click( function() { $( selector ).each( function( i, element ) { $( $( element ).attr( 'href' ) ).removeClass( 'selected' ).css( 'display', 'none' ); }); $( this ).addClass( 'selected' ); $( $( this ).attr( 'href' ) ).css( 'display', 'block' ); return false; }); }); if ( !start ) start = $( selector + ':first' ).attr( 'href' ); $( selector + '[href=\'' + start + '\']' ).trigger( 'click' ); };

Ну я это все к тому, что привести в порядок верстку в большинстве шаблонов, в частности, под opencart, нужно потратить не один час времени (и чем сложнее дизайн и неграмотнее изначальный создатель шаблона, тем больше времени придется убить на валидацию). Если это делается "чтобы глаз радовало", то это одно, но тут вроде как обсуждали отношение поисковиков к верстке и ошибкам в ней, значит цель-то немного другая. А для поисковиков, вместо убивания 5 часов на создание валидной верстки, лучше это время потратить на написание уникальных, сбалансированных текстов с ключевиками (за 5 часов вполне можно наполнить текстами главную и десяток узлов каталога, толку от этого для ранжирования будет на порядок больше, чем от валидной верстки). PS: а по Вашему вопросу по jQuery, так сходу сказать, в чем проблема у Вас не получится (не известно, какие дополнения к jQuery ставили, что в самом jQuery правили, что именно и как на нем реализовано и т.д., скорее всего, проблема именно в плагинах/скриптах на jQuery, а не в нем самом). Нужно смотреть полную картину, а то получается вопрос типа "у меня не заводится машина, вот фотка передней панели в момент завода" (без обид). :)

Ой, народ, вот вы заморочились-то. Поисковикам глубоко фиолетово 95% ошибок, которые показывают валидаторы. На ошибки CSS им вообще плевать (а без них, зачастую, кроссбраузерную верстку не сделать). JS тоже не интерпретируется, и на ошибки в нем тоже побоку. Самое главное, для поисковиков, чтобы семантически в верстке не было грубых ошибок, и только, т.е: - теги закрыты корректно (чтоб вот такого не было): <form> <div> <p>какой-то-текст </form> </div> - правильно расставлены акценты (чтоб вот такого не было): <strong>и-тут-пошло-полтора-экрана-текста</strong> - блоки использовались по назначению (чтоб вот такого не было): <style> .b-as-div { display: block; width: 400px; height: auto; } .b-as-header { display: block; width: 100%; margin: 10px; text-align: center; } .b-as-paragraph { display: block; width: 100%; text-indent: 20px; text-align: left; } </style> ........... <b class="b-as-div"> <b class="b-as-header">Заголовок</b> <b class="b-as-div"> <b class="b-as-paragraph">какой-то-<b>текст</b></b> </b> </b> кстати, пример выше абсолютно валиден (ну если раскидать стили и тело по header и body) и человек в браузере его будет видеть как надо, но при этом от такого любой поисковик взвоет и не ровен час, забанит страницу за поисковый спам. - Чтоб верстка была максимально компактная (чтоб вот такого не было): <div> <div> <div> <div> <div> <div> <div> <div> <div> <div> какой-то-текст </div> </div> </div> </div> </div> </div> </div> </div> </div> </div> На общепринятые ошибки глаза закрываются (такие как незакрытые img и input-ы) обычно. А все остальное - на усмотрение самого веб-мастера. Кардинально использование div-ов или таблиц, а также валидность на позиции не влияет никак. Просто при переверстывании на div-ах документ более структурирован получается (если верстали с умом), это роботам нравится, при проверке валидности правятся ошибки, которые могут помешать роботам увидеть контент (незакрытые теги) и упростить разбор, что в итоге дает большую частоту индексации и попадание в индекс всей страницы корректно. Но есть и примеры, когда в коммерческий топ с 700.000+ запросов/мес выходят сайты с грубыми ошибками в верстке, разваливающиеся в разных браузерах, да и вдобавок сверстанные таблицами, зато с уникальными текстами и хорошим ссылочным.

В Вашем случае, добавьте background-position: 0 62px; в стили "#header .div4 a.selected" и "#header .div4 a".

Что именно смущает? diff содержит изменения в файлах, все можно посмотреть глазками, при наличии знаний по PHP. php-скрипт ищет все поля в таблицах базы, заканчивающиеся на "_id" (скорее всего будут участвовать в джойнах), проверяет, есть ли на это поле одиночный индекс и, если нет, выводит в поток вывода (консоль или браузер) запрос для добавления индекса на это поле. Полученную кучку запросов выполняем в phpmyadmin. НО! т.к. diff снимался с переправленного магазина (правки касались не только скорости), то что-то может быть лишнее (хотя вроде все вычислил) или чего-то не хватать, так что пользоваться всем этим на работающем магазине не советую, обкатайте сначала на локальной копии. Если будут какие-то проблемы - готов подсказать.

День добрый, комюнити. Есть ряд наработок по оптимизации количества запросов к БД в ocStore 0.2.0 (проделывалось на магазине в 200+ категорий и 2000+ товарных позиций), в частности: - Все категории грузятся одним запросом; - Исправлены запросы с участием языка (убран один JOIN); - Добавлено множество индексов на таблицы; - Ряд мелких правок в коде для отладки и оптимизации работы; По итогам, вместо более 1000 запросов к базе на генерации морды получил 140+, и ускорение генерации страниц с 1200мс до 200мс (при отключенном кешировании запросов). Во вложении - diff от ocStore v0.2.0 (базовой) и скрипт генерации запросов для создания индексов (на всякий случай, на все "..._id"-поля, где-то, может, и переборщил, но все-равно лучше стало, чем было). Также есть правки для дополнения SeoUrl_ocStore_0.2.0.zip (не помню, входит оно в базовую сборку или нет), тоже на уменьшение количества запросов. Если данная работа актуальна сообществу хотелось бы, чтобы она попала в репозитарий и в будущие релизы (очень уж не хочется при обновлении перетаскивать все это каждый раз). PS: убедительная просьба ставить diff аккуратно и внимательно, предварительно забекапив скрипты и базу. PPS: в будущем готов проделать тоже самое и для ocStore 1.х (по крайней мере посмотреть, что там и как), когда доберусь до переноса магазина с 0.2 на 1.0. db_index_hotfix.php preformance.diff.txt