100napb

это ни о чем не говорит. sleep. спящий. он уже отработал и просто ждет завершения. может я конечно чего-то не догоняю, но какая-то странная проверка =\ какой толк от проверки скорости запросов, которые не работают \ не используются? я к тому, что у Вас на страницах сайта не работает поиск от sv. С таким же успехом я могу сказать Вам, что я то же все проверил, и поисковые запросу к сфинксу выполняются за 0.001сек. Ну правда ))

очевидно, что генерация страниц Вашего сайта создает значительную нагрузку на виртуальном хостинге. Вероятно, у Вас очень низкая скорость ответа сервера (время получения первого байта, TTFB). Из-за этого Вам и хостер шлет предупреждения, и из-за этого же будет страдать индексация поисковиками (они не любят сайты с медленным ответом и не любят долго ждать) Многие не знают как заманить ботов к себе на сайт. А Вы просто не можете справиться с их временным наплывом. Вам нужно в первую очередь озаботится тем, что бы провести какую-то минимальную оптимизацию, улучшить время первого байта и снизить нагрузку на сервер. И в последнюю очередь думать о том, что бы вводить какие-то дополнительные ограничения для ботов (кроме необходимых) Самый простой совет: - проверьте, по каким страницам ходят боты. И какие именно боты. Убедитесь, что у Вас в роботс.тхт закрыты страницы фильтра со всякими установленными параметрами; что файлы выгрузки в яндекс-маркет или иные маркеты работают быстро или генерируются по расписанию и отдается уже готовый файл, а не динамический фид. - что отключен подсчет количества товаров в категориях в административной части опенкарта или настроено какое-то их кэширование (подсчет количества создает ощутимую нагрузку на сервер)

вероятно, работает штатный-коробочный поиск, если судить по тому, что а) поле ввода поискового запроса выглядит "стандартно" б) не назначено никакого ивента и нет live-поиска в) на страницах отсутствуют js-скрипты от модуля авторства sv2109 убедитесь, что модификатор модуля поиска включен и применен без ошибок. если, конечно, планируете использовать модуль от sv, а не поиск на основе сфинкса. PS:

В пхпмайадмине: -- скрипт для формирования запросов по смене движка таблиц в рамках выбранной базы данных. Например: InnoDB <--> MyISAM ------------------------------------------------ -- указать название базы данных set @DB_NAME = 'dbname'; -- указать на какой движок меняем set @DB_ENGINE_NEW = 'InnoDB'; -- указать с какого движка меняем set @DB_ENGINE_OLD = 'MyISAM'; ------------------------------------------------ SELECT CONCAT('ALTER TABLE `',table_name,'` ENGINE = ', @DB_ENGINE_NEW, ';') AS sql_text FROM information_schema.tables WHERE table_schema = @DB_NAME AND ENGINE = @DB_ENGINE_OLD AND TABLE_TYPE = 'BASE TABLE' ORDER BY table_name DESC; На выходе-результате будет набор команд для ручного выполнения (при выполнении скрипта движок не будет изменен). Желательно их сохранить для спокойствия в какой-нибудь документ. Результаты необходимо скопировать и выполнить отдельно.

попробуйте для начала добавить \ вот так

наоборот же - растет :)) впрочем, неважно.

че-то тормозит немного...

Поисковые пауки не будут столько времени ждать. У них миллионы миллионов сайтов кроме Вашего ещё на очереди. Факт: скорость и глубина индексации поисковиками зависит и от скорости работы сайта. Быстрый ответ сервера ценится и тут. Что так же не в пользу кэширования как единственной оптимизации

кэш имеет свойство устаревать\инвалидироваться. В опенкарте кэш из коробки имеет глобальное время жизни, которое по-умолчанию 1 час. Разумеется, Вы можете установить время его жизни хоть 1 год, но с таким же успехом можно кэшировать страницы сайта целиком и показывать их клиентам как набор статических html-страниц. Супер-быстро *сарказм* Иными словами, для большинства ситуаций это такое себе решение - устанавливать длительное время жизни кэша. То же самое касается jetcache и любого иного модуля-кэшера: после добавления новых товаров, изменения структуры категорий, введения или изменение атрибутов или опций - все это ведет к тому, что рассчитанные и сохраненные вычисления в кэше становятся неактуальными и должны быть удалены\пересчитаны\закэшированы повторно. Потому нет, не верно. Кэширование - это отличный прием. Но это должно быть "последней линией обороны", а не первичной(единственной) оптимизацией. В противном случае, быстрые страницы из кэша - это в какой-то мере просто попытка спрятать медленный магазин

Обратитесь к автору модуля для уточнений. Насколько я знаю, на холодную все эти тормоза будут (при первом открытии или открытии категории или после очистки кэша). Что бы в два клика и бесплатно ?)) я таких не знаю. По приведенной выше ссылке самое простое и весьма эффективное решение предлагал Soor: подключать к запросу вычисления рейтингов, акционных цен и прочего только по требованию-необходимости, оставив в выборке запроса только product_id. При некотором понимании сути это реализовать не сложно. Да, надо переписывать запрос и править код. Если не собираетесь качать скилл и разбираться в программировании и основах "подкапотной" работы, то проще всего нанять специалиста, на мой взгляд. Самолечением без компетенций Вы рискуете навредить себе и своему магазину или усложнить его дальнейшее обслуживание\администрирование. Впрочем, решать Вам...

если готовый вариант, то можете использовать какой-нибудь модуль кэширования. Тот же jetcache, например. Либо, за некоторую сумму можете поискать исполнителей на банальные this->cache-> set() + this->cache->get() вокруг результатов подсчета или даже на какую-нибудь оптимизацию самого запроса, что бы и "на холодную", без результата в кэше, было быстро

можно. - самым банальным будет совет отключить подсчет количества товаров в категориях в настройках магазина. если не хотите отключать, то их можно оптимизировать и кэшировать. - более продвинутым будет некоторое упрощение\оптимизация sql-запроса, отвечающего за выборку пачки товаров внутри категорий и их пагинацию (getProducts). Вот тут, например, можно прочитать. - свой VPS с выделенными ресурсами так же имеет значение. На шаред-хостинге стабильно получать хорошие результаты почти невозможно. - ну а если уже никакие индексы не помогают, сервер хорош, и у Вас 50к+ товаров в одной категории, то наиболее эффективным и наиболее дорогим будет вариант смены основного хранилища данных (sphinx, например) или его реструктуризация с денормализацией таблиц. Эти решения позволяют делать выборку товаров за десятые или даже сотые доли секунды. Минусы: нужен компетентный и недешевый специалист; изменится модель и запросы для работы с каталогом и потребуется адаптация фильтра, скорее всего.

как вариант.

Спасибо за скриншот. Действительно И заменить на order by z.name, p.pr_name

ой

Проще простого. Красным выделил размер скидки(0.3 означает -30%), а зеленым закомментирована строка на случай, если нужно делать скидку лишь на товары одной\нескольких конкретных категорий товаров; фиолетовым - дата начала и конца акции

Вопрос с подвохом: а Вы смотрели результат выполнения sql-запроса в том же phpmyadmin'e, прежде чем выстраивать логику в контроллере основанную на вложенных циклах? это не оптимально и медленно. Все решается одним sql-запросом вида Результат запроса в базу возвращает полностью готовый результат. Совершенно неудивительно, что у Вас партнеры одинаковые получаются, поскольку вместо того что бы выполнить лишь один раз простой и быстрый запрос, Вы его дергаете в цикле для каждого региона и он Вам на каждой итерации послушно снова и снова возвращает уже готовый список, который начинается с одних и тех же записей.... Вам просто надо распарсить результат $this->model_information_partners->getPartnerss(); в удобный для вывода в шаблоне массив и все.

это не оптимально и медленно. Все решается одним sql-запросом вида

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

Ваша проблема связана с двумя моментами: 301 редиректом и настройками сеопро. Попробуйте, для начала, в настройках магазина изменить вариант ЧПУ

рад, что Вы что присоединились к обсуждению, спасибо. поскольку варианты сортировок строго определены списком, который предлагается пользователю во фронте, то кажется логичным использовать виртуальные(хранимые) или предварительно сгенерированные столбцы со значениям в бд. По одной колонке вместо какого-нибудь "order by sort_order, lcase(name)" и содержащие, например, порядковый номер записи согласно того или иного варианта сортировки. Составные индексы в mysql вкупе с этим так же более-менее успешно работают. Более-менее ввиду того, что составные индексы по-умолчанию сортируются как asc и они не эффективны при выполнении запроса, в котором для второго или последующего поля используется сортировка desc. действительно, есть. но насколько я помню она не эффективна в случаях, когда подзапрос или джоин, содержащий оффсет, становится довольно сложным и субд не может его выполнить использовав только индекс. Потому для пагинации результатов фильтрации не подходит, я думаю

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

Без всякой иронии, вопрос чисто из любопытства: почему с этой шляпой ничего не сделали? Речь о том, что чем глубже страница, тем медленнее отрабатывает запрос выборки товаров. Оффсетная пагинация на таком количестве товаров - это же откровенно гм... не лучшее решение =\ Впрочем, для опенкарта еще никто этот вопрос не решил, по-моему. Во всяком случае в паблике не припомню упоминаний об этом. Страницы категорий от краулеров на сайте не закрыты - значит они довольно часто и много путешествуют по ним, создавая приличную нагрузку и ожидая ответа порой довольно много. Или в этой оптимизации просто нет смысла? [censored]

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