Yoda

Вы ведете себя как толстая баба, на которую коктельное платье размера Х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 году не понимает что это хлам?

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

Я много раз про это писал. Чем ваш, Васи, Пети магазин, на каком-то стандартном шаблоне, отличается от еще 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 и ссылаться на основную страницу категорий. На основной странице каноникала не должно быть, страница не должна быть каноничной самой для себя. На сегодня это единственный корректный набор правил. Именно для Гугла.

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

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

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