Yoda

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

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

Потому что загаженные Жигули типа тоже машина. По факту сервер и провайдера надо выбирать исходя из многих факторов. Основные три это наличие свежего мощного железа, коэффициент оверселла и понимания саппортом как работает стек 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 году не понимает что это хлам?

Тоесть вы больше верите розетке, а не официальному представителю гугла. Хм...

Я много раз про это писал. Чем ваш, Васи, Пети магазин, на каком-то стандартном шаблоне, отличается от еще 10 000 таких же ? Вот регулярно видишь магазины в которых какой нить ткач модуль нагенерил описаний.. КУПИТЬ ДЛЯ ДОМА ДЕШЕВО ПО НИЗКОЙ ЦЕНЕ ДОСТАВКОЙ ПО УСТЬ УЙДУЙСКУ! Что для дома, куда для дома.. Или в товаре Хрень. Для дома в интернет магазине хрень для дома купить. какая то хрень доставка цена.. Ну кому это надо ?

FAIL! C таким же успехом вы можете сделать в роботс disalow page!

Хотите совет на миллион долларов. На 999.9 процентов, у вас нихрена не описаны качественно ни категории, ни товары. максимум какой-то гавно-генератор от ткача "купить беслпатно по ценам доставки ниже рынка в усть уюйске". Если потратите месяц по 2 часа в день, каждый день, 60 часов, каждый день после работы и в выходные, и сделаете НОРМАЛЬНЫЕ.. Нормальные мазафака тайтлы категориям и товарам, и ту самую структуру. Наживете много трафика! Я уже молчу про нормальные описания и ревью про топчик позиций, и экспертные статьи в категориях, а про бложик - я ваще молчу! Попомните папкины слова!

Но у нас есть несколько оооочень успешных проектов, где очень просто robots Disallow: /*? Все!!!! Но там очень хороший контент, отличная индексаций товаров без обхода по категориям. И вам всем лучше так не делать, пока у вас интернет-киоск, или ларек!

Бинго. кроме того что прев некст, надо убрать они ни в мзду ни в красную армию в нынешних реалиях!

У вас нет правильного ответа. А правильный простой. Prev next гугл не учитывает. https://twitter.com/JohnMu/status/1108719402558590976?ref_src=twsrc^tfw|twcamp^tweetembed|twterm^1108719402558590976|twgr^|twcon^s1_c10&ref_url=https%3A%2F%2Fd-8164586801860018679.ampproject.net%2F2102060044003%2Fframe.html Не закрывать ничего это стрельнуть себе у ногу sort, limit, order должны быть закрыты в роботс, иначе и дублей наплодите и нагрузку поймаете. Каноникал должен быть везде где есть get параметр page и ссылаться на основную страницу категорий. На основной странице каноникала не должно быть, страница не должна быть каноничной самой для себя. На сегодня это единственный корректный набор правил. Именно для Гугла.

Так ему сто раз говорили, что не надо прогревать кеш, а надо делать быстрые магазины. Хоть кол на голове теши хочь в очи в****ысь!

Я тут нашел в модуле одного странного персонажа вот такой текст: Мне кажется человек просто сумасшедший, с такими текстами, можно просто права на луну заявить и на имя ИЛОН МАСК! Может кто ему разъяснит что он ********. Странный человек и эта вся его филькина грамота яйца выеденного у коли балдина не стоит!

Может пить стоит перестать и не путать модуль поиска и фильтр ?

Ну ну, расскажите мне. что вы там получите с нормальной защиты? Список опкодов? Речь ведь идет не о том что ioncube взламывается - не взламывается, а речь о том, что фиг пойми что там под ионкубом, и что делать с этими решениями? Как поправить ошибки горе-разработчиков? Ну кодируйте реально какие-то свои уникальные вещи. кодируйте админку, без которой не заведется. Но кодировать модели критично важной инфрастуктуры, ну идите пианэры лесом!!!! Ни решений бибера, ни решений сосикриаторши у меня нет ни на одном большом серьезном проекте, выжгли как раковую опухоль! Если марк явно умудряется шеллы внедрять, то на что способна жадная сосикриаторша со своими непонятными бинарниками ?

Меткий ****** из техаса. В моей выборке персонажи, у которых аккаунтам больше 5+ лет. Я вижу явную тенденцию, что том, авара, марк и чукча бегали по темама впопад или нет и пытались сунуть свой нос чтобы им плюсиков наставили!

Ну так на то и секта! )

Небольшой сравнительный анализ. Берем во внимание, скорость, функционал и возможность вносить правки под те или иные задачи. И смотрим на MegaFilter Ocfilter и Viver. Ocfilter - быстрее всех, за счет pivot таблиц. Сео функционал есть и реализован правильнее всего, код открытый. Есть у меня там кое-какие претензии по архитектуре и организации данных в админке, но это мелочи. В целом - все великолепно! MegaFilter - шикарен с точки зрения настроек и тех-или иных твиков, которых нет нигде, как например подмена значений для атрибутов и вывод цветовой карты изображениями, а не текстом, сео часть присутствует, есть определенные проблемы с canonical, есть проблемы с навигацией по большому количеству посадочных, есть проблемы со скоростью, как генерации фильтра так и JS-скриптов, которые рендерят вывод фильтра на фронт, есть проблемы с переполнением кеша, частично закрытый код, но можно почти все решить. Filter Viver - криво и плохо все. Внешний вид с карамельными кнопками, застрявший где-то в 90х, полностью закрытый код модели фильтра, который на себя целиком перехватывает метод getProducts (вместо модифицрования как в предудыщих двух) и прощай любая оптимизация и внесение изменений. Что касается самого год, внутри к сожалению костыль на костыле, одни и те же методы дергаются по десять раз, выполняя ненужные запросы, сами по себе запросы оставляют желать лучшего и автор никак не шевелится чтобы это решить, хотя ему много раз про это писали. Своя реализация кеша, который разрастается как снежный ком и на 1000 записей в папке, дает сразу оверхед в 500-700мс. Что тоже нет возможности исправить. А теперь вишенка на торте. Если брать реализацию сео функционала в Mega и Ocfilter, в них есть основная концепция по умолчанию - посадочные сео страницы только те которые мы сами сделали и отдаем в поиск ровно то что нам надо, все остальные ссылки - это Ajax или get параметры, которые можно прикрыть от роботов и не кормить мусором ботов. У бибера же покупатели - жертвый горе сеошников, которые в своей жизни проект на 100 посетителей в день считают достижением всей жизни, вот они начитались, что все должно быть посадочными, бибер подхватил эту идею и для таких вот сделал фильтр. В итоге на магазине в 3000 товаров может появится хлама на полмиллиона страниц, на которые приходят боты. И что в итоге. Вместо того чтобы бот ходил на категории - он ходит на чехольчики_зелененькие_кожа_наличие_ценаот_100_200 и так далее. Что мы получаем, какое то просто дичайшеее количество мусора, который должен обойти бот, сумасшедшую нагрузку на сервер. Отсутсвие в выдаче действительно важных страниц и товаров. Ну да ну да - ща прискачет бибер и скажет, у меня ж там ноиндес. Ага ага, только бибер забыл что для того чтобы этот ноиндекс увидеть, боту все равно надо зайти на страницу а серверу сформировать. Ну и полная дичь с каноникал! Все посадочные ссылаются на каноничную страницу на базовую категорию. И ни одного ответа, помог ли кому-то этот дьяволский костыль, пришел ли к кому-то хоть небольшой трафик - я не слышал. Зато регулярно слышу, так сеошники сказали. Очень жаль что не все могут думать своей головой и трезво оценивать ситуацию!

Серьезно? У меня есть магазин на 3м товаров. Поможет ?