Магазин на 1.5.4.1. Товаров чуть меньше 4500. Категорий 32. Включен seo pro. Через фаербаг проверяю время загрузки одной из категории: хостинг: GET/noutbook/ размер: 61.3 Кб время: 8c±2c денвер: GET/noutbook/ размер: 61.3 Кб время: 4c±1c при отключении seo pro время загрузки уменьшается почти в 2 раза. Разве это нормально при таком количестве товаров, что же будет при 10 тыс. товаров? Что в этом случаи можно сделать? Вот тут говорится что можно оптимизировать запрос списка товаров в категории с разбивкой на страницы, с сортировкой, запрос подсчёта общего количества товаров в выбранной категории и запрос формирования SEO_URL. Прошу пролить свет на данный вопрос. Или возможно необходимо закешировать запросы (или они и так кешируются?) В магазине количество товаров при покупке не вычитается, а потому в категории всегда одно и тоже количество товаров, обновляются раз в неделю. Поэтому зачем при каждой загрузке страницы делать такой запрос. SEO_URL так вообще не меняются.
Странно, но после установки на денвере разницы нет, кэш чистил. Кстати после добавления в \usr\local\mysql-5.5\my.ini строки query_cache_size = 64M время при повторной загрузки страницы уменьшается почти в 2 раза, как я понимаю часть запросов кэшируется. Однако на хостинге вносить изменения в конфиг mysql возможность у меня отсутствует... Есть ли ещё способ?
Добрый день Просто, как вариант, может быть вам стоит заодно подумать о выключении подсчета количества товаров?
Было такое - первое что сделал - вырезал подсчет и товаров и категорий, второе стал искать скрипты и стили загружаемые со сторонних ресурсов - перелил их к себе на хост, третье - воспользовался PageSpeed и после его анализа исключил еще несколько тупящих моментов...
Посмотрел сколько запросов формируется при загрузке страницы категории. Всего получилось чуть больше 250 шт, причём 190 из них делает модуль "Текстовые атрибуты". И это для вывода 4-х атрибутов в каждом товаре. После его отключения претензий к скорости загрузки больше не имею. Может это из-за большого количества атрибутов, или какой-то личный баг, но модуль увеличивал время загрузки страницы в несколько десятков раз. Вот так. P.S. вопрос оптимизации запросов остаётся открытым. Может кто-нибудь поделится своими наработками в этом направлении?
Оптимизация запросов - это сокращение количества запросов путем разумного кеширования. Это то, что можно сделать, не влезая глубоко в движок сайта. Как кешировать - выбирать вам исходя из возможностей. Я закешировал псевдостатические данные, которые очень редко меняются - данные информации, которые порождают около 5 запросов на генерации каждой страницы. Таких мест каждый может выделить достаточное количество.
denya, Оптимизация - не совсем то что Вы думаете, как можно сократить запрос если он только 1 и достает все что надо из 1 таблицы, будете делать 2-3 запроса и доставать по очереди? Не самый лучший выход... Оптимизация ето максимально упрощена конструкция выборки данных, ето если писать так как Вы... И хотелось бы знать как Вы закешируете запрос который выполняется при поиске на сайте?
Если запрос 1, то понятное дело, что практически ничего не сделаешь, но я привел пример, когда у нас идет обращение к таблице information за каждой частью "информации" - "доставка", "о нас" и т.д. итого происходит около 5 запросов с соединением таблиц в базе. Что если мы закешируем результат запроса для всех "информаций" и поместим хеш в статик переменную (разместим в памяти), тогда, прочитав кеш с диска единожды мы получим экономию на этих 5 запросах - нам не нужно будет пинать базу по этому поводу, оставив ресурсы на более затратные выборки Я и не писал, что все можно закешировать
denya, В information нет больших данных и нет таких глобальных запросов как Вы пишете об етом... Хоть убейте но не верю что из за етих запросов получения данных из information система тормозит. Тормозит из за рекурсивного дерева категорий и получения списков товаров. Про поиск молчу как рыба, так как там вопше...
Yuriy_Z, согласен с Вами, что "информация" - это мелочи, но, как я понял, человек ищет пути любой оптимизации. На его примере отключение 1 модуля сняло значительную нагрузку на БД. Тоже встречал такие модули - например OCU Waitlist, который проверяет наличие каждого товара в листе ожидания. Единой кнопки "Ускорить" нигде нет Поиск - это вечная проблема у всех, особенно полнотекстовый.
