Yoda

Я еще раз пишу. Все модули кеширования - это вата в лифчик! Если у вас сайт тупой, ему никакой лайтнинг и джет кеш не поможет. А сайт тупой может быть по сотне причин, начиная от странного кривого хостинга, заканчивая структурой каталога и загадочными модулями. А все разработчики которые продают кешеры под видом панацеи от проблем, просто наживаются на болях владельцев магазинов, и зачастую приносят больше вред чем пользу. Но бабло не пахнет. Бог им судья!

Менять хостера, который не может вам сделать норм окружение! Обычно переезд на свежую версию - это новый магазин с нуля со всеми затратами которые были до! Не слушайте эти советы типа, че там обновится. Обычно фрилансеры не понимают, сколько люди кладут в магазин, чтобы он работал. И тем более не понимают, что любой переезд обновление - это столько же еще!

@SooR Сааань, обьясни невменосу пожалуйста.

Серьезно? Может у вас какой то другой окфильтр. Он в том то и дело, Что выводит ссылки - если есть посадочная! А если нету - js редирект!

А еще не хватает вот прямо очень встроенного набора иконок поздравлений с восьмым марта, чтобы мигали! Чтобы глаза прям вот взяли и вытекли. И чтобы пхп на русском. взятьмассив как массив (вывести ворыч массив) { массив->изгоняем_идиотов_из_оксторе()->run }

Поддержу! Самому крайне не нравится этот участник, и странные отзывы от новорегов на него. Но все таки лучший фильтр у @SooR. Мне очень нравится фильтр от @OCMegaExtensions в плане гибкости настроек, но у него критичные проблемы с seo, совершенно адская бизнес-логика кеша и архитетурных вопросов связанных с построением базовых наборов значений, и большие проблемы по фронту, вот это все див в диве в ul в li в span, и потом это все мы еще считаем высоту ширину... Вобщем лучшее враг хорошего и они жестко угнались, равно как и в FULL TEXT индексах которые совсем не про это, а find_in_set - это тупая поделка которая не может хорошо и быстро работать. Вобщем. Фильтр был бы вне конкуренции, если бы не это все. Грубо говоря откровенное непонимание разработчиками проблем больших магазинов, я уже молчу про отсутствие гарбаж коллектора для файлов кеша, и по 2 файла на набор. Но не будем о плохом. Мега - отлично подходит для небольших магазинов до 5-10 к товаров. Если ее правильно настроить и еще кеш впихнуть в memcache. А вот фильтр от @SooR наглухо лишен всех этих проблем. У него очень простой утилитарный модуль вывода параметров, который не отжирает ресурсы браузера, у него очень внятная ситуация с посадочными страницами, и он быстр как ветер. Да да.. я там какие-то свои идеи автору подсунул и он их реализовал, и спасибо ему.. Все остальные реализации.. Ну они не очень. Или дубли создают, или тупые, или кеша генерят сотни тысяч файлов, или не дают возможность оптимизации в силу закрытого года. Извините дорогие авторы, я не мать тереза, просто так рассказать что у вас не так - не могу, @SooR - мой друг, ему хоть звезду с неба.

Нет нельзя!

Только тру гуру опынкорд не могут без него. Это как вырезать крайнюю плоть, ты что.

В этом аспекте абсолютно. А по ситуации в целом. Человек начал заниматься вопросиками, где-то сунул принудительно в гугл страницу, где-то еще что, и сразу пошло активное сканирование... Прибрал дубли - вот немного результат. Но когда я слышу про через 5 дней рост + 20 позиций потому что... Ну это бред! У меня есть подопечные у которых лаг по росту позиций был в полгода. Сделали - все стало хорошо.. долго нудно. Потом ничего не делали и через 5 месяцев +700 хостов вдруг!

Ваш сервер - это когда он ваш физический! А когда это VPS у вас 40 соседей и один диск на всех. И процессор на 16 ядер, которых виртуальных могут продать 100! Это как у вас 40 баранов, но к колодцу очередь в одну тушу. Поддержка везде не очень. Проверено и работает после того как настроили там где есть быстрые свежие сервера. Если все настроено изначально ок. Поддержка не нужна!

Вы ведете себя как толстая баба, на которую коктельное платье размера ХS уже десять лет как не подоходит. Но чуть что визг- давайте книгу жалоб, вместо того чтобы осознать что жрать булок меньше надо!

На 120, а стал на 101 ))) Честно говоря этот пост превратился в анекдот. Вместо того чтобы просто прочитать официальные источники, гадание на кофейной гуще.

Очень стесняюсь спросить - а чем самое надежное? И в каком месте 1000+ инсталляций ?

Я вам выше дал исчерпывающий ответ на вопрос. Хостинг годится любой, на котором есть либо 5Hz intel, либо райзены. Понять кто сколько оверселлит сейчас без серьезных тестов не возможно. В вот этих всех таблицах с тарифами можно нарисовать любое количество ядер к примеру и памяти. А потом у вас окажется пару жирных соседей которые будут потреблять 80% ресурсов и ядра эти физически на каком-нибудь celeron сто летней давности. И потом вопросы, ой что-то не заработало. Или в панели opcache не включен, зато тех поддержка бесплатно перенесла. Или вот у вас три сайта. Вы их перенесете. А в какой конфигурации? На апач или на php-fpm ? В каком режиме будет работать php-fpm, сколько ядер у вас будет? Будете ли вы разграничивать проекты по пользователям, или все будет под одним? Вам ни один хостер не ответит на эти вопросы, а в случае чего у них один ответ - берите больше ресурса, ограничивайте ботов. Так что еще раз повторю. Любой хост, будь то хост про, админвпс, рег ру, тайм веб, но быстрый процессор. А условно бесплатный саппорт - везде не очень.

Мне не надо ответов. А тем более на таком мелком промежутке - это не показатель, а глупости.

Ошибка выжившего. Рост произошел потому что мусор вывалился. А с каноникал и прев некст - бред!

Этот пост надо в шапку форума закрепить. Наконец-то реальная оценка всем этим приблудам!

Потому что загаженные Жигули типа тоже машина. По факту сервер и провайдера надо выбирать исходя из многих факторов. Основные три это наличие свежего мощного железа, коэффициент оверселла и понимания саппортом как работает стек LEMP. Все остальное мишура, так как надеятся на условно бесплатную техподдержку за 300 рублей, это также как верить в огурец от гемморя. Просто как пример. Девять из десяти хостеров отдают isp панель по дефолту. А то что mysql старый, nginx не включенный, так это проблема индейцев, хотя достаточно а сетап контейнера дописать 20 строк.

Мда уж, почитал ваш холивар. Смешно. У одного оратора попытка натянуть сову на глобус и приводить примеры из базы с почти на порядок меньшим количество данных, а так же с какой то теорией про измение логики выборки, хотя нам вот нужна именно такая и никак иначе. Есть определенная реализация и нам надо решить имеенно ее, а не придумывать велосипед и упрощать. Второй тупочет ножкой зачем-то про нативный кеш mysql. Не особо понимая, что кеш ничем не помогает, когда у тебя 3000 запросов по 0.001сек, это 3 сек, и кешируй их не кешируй, тут только работать в сторону уменьшения количества запросов. Еще один хочет что-то выпилить, и предлагает кэпские решения, которые итак понятны, но ни на что не влияют, так как проблема всей этой конструкции, в том, что на 100 000 товаров производится 100 000 подзапросов count, по полю другой таблицы, в которой 140 000 записей, и вот в этом самая большая проблема. В том что каждый раз, на каждую категорию производится вот этот вот COUNT(order_id). Ну и здесь есть несколько вариантов решений: 1 - просто забить и сделать именно для этих результатов длинный кеш, скажем на сутки. Но у нас 300-400 пользователей получат долгую загрузку страницы, больше 5-6 сек. 2 - Запустить плановую агрегацию, крон, который будет перебирать значения и считать их раз в сутки под каждую категорию. Но у нас есть проблема, запрос 6 секунд, на 300 категорий, это 1800 секунд у нас занято ядро сервера, раз в сутки, которое будет просто в холостую гонять эти каунты. 3 - Cамая пожалуй верная реализация, это сделать промежуточную PIVOT таблицу, в которую мы посчитаем общее количество продаж по каждому товару за последний месяц, одним длинным запросов в 5-7 секунд. А потом уже будем выгребать данные из нее, учитывая что у нас в ней сразу есть все поля как для сортировки так и для группировки, mysql сделает это очень быстро с использованием составных индексов, на прототипе у меня вышло, что то около 0.18сек, вместо наших исходных шести. И вот потом уже можно эти данные кешировать в самом движке, либо прогреть их в какую-то агрегатную таблицу, и оттуда забирать дополнительным запросом, но так или иначе, мы сэкономим ресурс сервера (проект нагруженный), и отдадим пользователям быстрые страницы, ровно с теми данными, которые изначально нам были необходимы. Хейтеры, в бой, можете начинать рассказывать какие вы умные, а я тупорылый!

Индексы нужны не для рационального соединения, что за бред. Какая то фантастическая фантастика, человек выдумал mysql... Идем в официальный мануал и читаем: Индексы применяются для быстрого поиска строк с указанным значением одного столбца. Без индекса чтение таблицы осуществляется по всей таблице начиная с первой записи, пока не будут найдены соответствующие строки. Чем больше таблица, тем больше накладные расходы. Если же таблица содержит индекс по рассматриваемым столбцам, то MySQL может быстро определить позицию для поиска в середине файла данных без просмотра всех данных. Для таблицы, содержащей 1000 строк, это будет как минимум в 100 раз быстрее по сравнению с последовательным перебором всех записей. Однако в случае, когда необходим доступ почти ко всем 1000 строкам, быстрее будет последовательное чтение, так как при этом не требуется операций поиска по диску. Все индексы MySQL (PRIMARY, UNIQUE, и INDEX) хранятся в виде B-деревьев. Строки автоматически сжимаются с удалением пробелов в префиксах и оконечных пробелов (see section 6.5.7 Синтаксис оператора CREATE INDEX). Индексы используются для того, чтобы: Быстро найти строки, соответствующие выражению WHERE. Извлечь строки из других таблиц при выполнении объединений. Найти величины MAX() или MIN() для заданного индексированного столбца. Эта операция оптимизируется препроцессором, который проверяет, не используете ли вы WHERE key_part_4 = константа, по всем частям составного ключа < N. В этом случае MySQL сделает один просмотр ключа и заменит выражение константой MIN(). Если все выражения заменяются константой, запрос моментально вернет результат: SELECT MIN(key_part2),MAX(key_part2) FROM table_name where key_part1=10 Производить сортировку или группирование в таблице, если эти операции делаются на крайнем слева префиксе используемого ключа (например ORDER BY key_part_1,key_part_2). Если за всеми частями ключа следует DESC, то данный ключ читается в обратном порядке (see section 5.2.7 Как MySQL оптимизирует ORDER BY). В некоторых случаях запрос можно оптимизировать для извлечения величин без обращения к файлу данных. Если все используемые столбцы в некоторой таблице являются числовыми и образуют крайний слева префикс для некоторого ключа, то чтобы обеспечить большую скорость, искомые величины могут быть извлечены непосредственно из индексного дерева:

Дед, пей таблетки! Из запоя давно вышел ? Тут человек пришел спросить помощь, а не слушать твои старческие бредни про нет или есть у него бабки! Че ты нос свой суешь где помочь не можешь... Это у алкашей так принятно. Мимо кто-то проходит. ЭЙ... А ты чоооо кудааа.. ээээ. дай пятерочку. Ты ж в приличном обществе, а не у себя на мусорке! Выдано предупреждение: - флуд Наказание: - ограничение публикаций

@dinox, ну только одна гроза нищебродов испарилась в далях финики, второй мастер. Гони бабки появился. Может как-то в оферте зафиксировать баны за попрошайничество, кроме раздела платных услуг ?

Привели мне пациента... 500к товаров 7к уников в день 150к записей в таблице order. Вобщем не ларек. И вот на категории в 50-60к товаров этот не ларек генерится 12 секунд! Не ну а че... Это ж опенкарт... Это ж не годится для больших магазинов. Никто не смог помочь. Как обычно вот эти сказки школотронов от программизма. В среднем страницы загружаются 2-4 сек, делаем быстро.все решаем, получаем 200-400мс, но на больших категориях все равно дичь. Смотрим запросы находим вот такое прекрасное, да еще и дважды инициализируемое: $sql = "SELECT p.product_id, (SELECT Count(op.order_id) AS popular FROM oc_order_product op LEFT JOIN `oc_order` o ON ( op.order_id = o.order_id ) WHERE op.product_id = p.product_id AND Adddate(o.date_added, INTERVAL 30 day) < Now() AND o.order_status_id > '0' GROUP BY op.product_id ORDER BY popular DESC) AS popular FROM oc_category_path cp LEFT JOIN oc_product_to_category p2c ON ( cp.category_id = p2c.category_id ) LEFT JOIN oc_product p ON ( p2c.product_id = p.product_id ) LEFT JOIN oc_product_description pd ON ( p.product_id = pd.product_id ) LEFT JOIN oc_product_to_store p2s ON ( p.product_id = p2s.product_id ) WHERE pd.language_id = '1' AND p.status = '1' AND p2s.store_id = '0' AND cp.path_id = '". (int)$category_id ."' GROUP BY p.product_id ORDER BY ( p.quantity > 0 ) DESC, popular DESC, Lcase(pd.name) DESC, p.date_added DESC LIMIT 0, 3 "; Ржавый фак и Винни-Пух. Это просто какая то жестяная жесть, джоин на джоин на джоин, при чем наборы 60 к товаров, 300 категорий и порядка 10-20к заказов. И сложная сортировка-группировка этого всего по разным таблицам, да еще и по предвычисляемому полю p.quantity > 0 все те школотроны, которые в гугле прочитали страшно умное слово индексы, тут сразу такие присели... При таких запросах индексы в принципе не могут полноценно работать. Вот реально представьте, для того чтобы выбрать 3 самых популярных товара из категории... Вот такое днище... А теперь вопрос знатокам.... А что же делать ? Как оптимизировать эти процессы? Ну кеш вы скажете понятно, но ведь кеш у нас так или иначе должен прогрется для всех категорий, рано или поздно он протухнет, и все равно кому то из клиентов попадется тухлая страница на 10-12сек, да и там не одна не две жирные категории. 7 секунд или 12.. Разницы особой нету. Вобщем задачка со звездочкой. Как сохранить полностью логику этого запроса без изменений базовых таблицы движка и отдать быстро эти данные холодными без всяких кешей ? Если что, мы с 6 сек на этом реализации, получили 0.18 мс.

Очень большая проблема заставить ПС часто реиндексировать хламосайт! Соответственно, чем лучше первичный контент - тем просто тупо вы меньше времени теряете на раскачку.

Ну и как вы думаете, алгоритм пс в 2021 году не понимает что это хлам?