Yoda

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

Не слушайте никого. Смотрите на топ, и делайте также. Почему это так сложно? Вы думаете какой-то сеооптимлаб, вам что-то толковое посоветует, да умел бы он хоть что-то и знал. Не было бы его тут рядом. Или работал дорого на постоянных клиентов, которых очередь, или свои магазины держал. Только включать мозги и только смотреть на топ.

А это что реально проблема?

Любой лишний слой абстракции - это по умолчанию оверхед ресурсов. Тут и так всё не очень со структурой базы. А они ещё ORM хотят. Я очень часто вижу медленные магазины и очень много. До пяти шести сотен проектов в год. И чтобы сделать магазин быстрым, зачастую лезвием приходится вырезать глупости и тупости, как Даниэля так и сторонних разработчиков. А если ещё на эту кривую структуру подвесить лишний слой. То это Будет не опенкарт а слоупоккарт. А вот query builder с возможностью манипуляций над любыми запросами, мог бы решить очень много вопросов.

Вы работали с базами на сотни тысяч записей, в которых у сущностей пару сотен неоднородных свойств. Какой простите orm в такой ситуации? К чему эти все предварительные глобальные инициализации наборов, а потом выборка путем перебора огромного объекта в памяти. Расскажите про ORM любому архитектору мало мальски нагруженного проекта, где каждая лишняя итерация это ещё пару лишних железных серверов. И тогда поговорим. А эти миллеинальные восторги технологиями ваши, я не очень разделяю.

Orm - зло и оверхед. Вот query builder.

Такое подойдет ?

https://github.com/opencart/opencart/blob/master/upload/index.php Похоже даже 3.1 не будет! О как! И вот: Тут даже какой то PSR появился. Не прошло и пару лет: https://github.com/opencart/opencart/blob/master/upload/catalog/view/javascript/bootstrap/js/bootstrap.bundle.min.js Огогого: https://github.com/opencart/opencart/blob/master/upload/catalog/controller/common/header.php Копмозер, aws. Вот я прямо ща вижу. Как у некоторых разарбочиков с видео школами и десятью годами в опенкарте подгорит! Чуток стек поменялся, уже не получится просто красить кнопки. Ну и вот это вот: https://github.com/opencart/opencart/wiki/Modification-System As of OpenCart 3.1.0.0+ OCMOD will be removed from the OpenCart source code. Only the event system will be used for modifications. Вот ща еще больше начнет бомбить у разработчиков с десятилетним стажем. Как же они без Ocmod. Сказать честно я слабо себе представляю как что-то суровое сделать без ocmod через события. Ну допустим фильтр. Либо через дикий оверхед по ресурсам, либо через подмену целиком методов, что создаст коллизии с другими методами. Ну прикиньте вы делаете фильтр товаров, а кто-то добавляет еще сортировку по наличию на складе больше нуля. И что? Куда это и как? Ладно бы данила всунул конструктор запросов и дал возможность в них внедряться вместе с событиями. А ту как быть event->pre->getProducts {bla bla bla use my_method; return my_method->$result;} ? Upd: https://github.com/opencart/opencart/blob/master/upload/catalog/model/design/seo_profile.php А это что ?

Там тематика магазина, которую ни Яндекс дзен ни Гугл ЭДС не показывают, чистая органика.

Порадовался я тут значит этой истории Сделал промочку на вторую часть... И... Все опять накрылось медным тазом. На следующий день после того как магазин зажил полной грудью он опять начал тупить при чем жестко. И если фронт работал кое-как, то вот товары обновить возможности не было никакой. Но давайте с самого начала. С чем мы столкнулись. Магазин на 65 000 товаров, самая большая категория на 10к товаров, у каждого товара 5-8 атрибутов. Из бредомодулей стоит jetcache и filterviewer. Жил себе и жил этот магазин на обычном виртуальном хостинге, пока не начал потреблять порядка 30% физического сервера хостинга, превышая в пике допустимый лимит нагрузки пакета в 10 раз. Когда я первый раз увидел этот проект, у меня было однозначное мнение, что это мертвый проект, так как скорее всего какой-то сеошник посоветовал сделать вот эти все посадочные под все со всеми и глаз пал на FV. В чем печаль ситуации. Этот фильтр генерит явную ссылку на страницы фильтра в формате все со всеми атрибуты, опции, и еще вот это в наличии и по рейтингу. И вместо того чтобы сделать явными только посадочные, а остальные страницы спрятать за js-редирект, а еще бы и закрыть по какому то признаку в robots, как тот же ?mfp= в Мегафильтр, viewer такой возможности не дает. Так как это же сео, это посадочные, это сеошники так сказали. В итоге боты прриходят и застряют в этом болоте из сотен тысяч мусорных страницы фильтра, вместо того чтобы приходить на нормальные страницы товаров, категорий и руками созданные размеченные посадочные с адекватными тайтлами и контентом. Ща прибегут хейторы и скажут йода опять несет чушь. Предлагаю любому хейтеру показать мне проект, где подобный финт ушами от вивер фильтра дали хотя бы +200 уников из органического поиска. И еще, viver говорит, что ну че там - ну у меня ж ноиндекс на второй третий уровень вложенности. Это все прекрасно и волшебно, но для того чтобы увидеть этот ноиндекс все равно надо сгенерить страницу, а их я напомню несколько сот тысяч. На которые пришли гугл, яндекс и бинг бот. Как говорит один мой знакомый, тут никакого сервера как у Пентагона не хватит. Ну и поверху всей этой красоты еще стоит jetcache, который создает видимость спокойствия. Не ну а че.. Ну из файлика же быстро html подгрузился по готовому кешу. А то что 3+ секунды загрузка на холодную. Так ну то фигня - самое главное же из кеша быстро, все 5 страниц которые туда попали и еще 50 000 страниц фильтра, а нормальный контент как был туп так и остался. Как грузилась категория на 10 000 товаров 5-6 секунд так и грузится (там еще нон стоп обновления товаров) и весь jetcache ходит по бороде так сказать. Но вот ложное чувство нормализации процесса давал. Ок. что делать? Перенесли сайт на впс - стало хуже. Так как на шареде, можно было забираться по уши в ресурсы соседей, а тут два ядра - и только они. И в этот момент владелец магазина обратился ко мне с вопросом, что же таки куда. И самое удивительное, он признал с первого раза всю дичь логики работы фильтер вивер и согласился его убрать. И поменять на OcFiltere от @SooR. После настройки серванта, после простановки индексов в базу, решения вопроса с кешами, выжигания filterviever и jetcache - у нас вроде нормализовалась работа. И получились вот те графики которые были в первой статье. Но это была только прелюдия.... Вчера опять проект лег в момент попытки обновить какие-то 6000 товаров. Начали разбираться и обнаружили падение базы. Начали смотреть почему падает, обнаружили нехватку памяти. Начали смотреть куда девается память - обнаружили оверхед потребления php-fpm. Начали разбираться почему - обнаружили, что в момент импорта-обновления таблиц mysql хоть их и не блочит, потому что innodb, но начинает подтупливать, потому что перестраивает индексы на больших таблицах. И в момент тупняка базы, становиться очередь запросов на генерацию страниц из php-fpm потоков, которые резервируют под себя память и в какой-то момент watchdog прибивает базу, как самый жадный процесс по потреблению памяти и пытается ее перезапустить, естественно убивая импорт и создавая проблемы для пользователей. Ну и оно в целом все время висит в момент импорта. Начали смотреть внимательней, и обнаружили в логах очень много зверей типа ahrefs, mj12 и других. Закрыли. Не полегчало. Попросил я дообавить 2 гигабайта памяти к 2 существующим на сервер. Добавили полегчало. И мало того, еще перенесли VPS на сервер с физической частотой процессоров в 5Ghz и вот тут полегчало глобально, импорт пролетел за какие-то 70 секунд. Все отлично. Прошли сутки. И сегодня опять мне прислали вот такой скрин: Со словами - там в логах очень много гугл бота. Я был готов уже проклять тот день когда я сел за баранку этого паровоза. Но нет. Все решили. И сейчас вот так И время ответа страниц без каких либо кешей 300-800 мс. С фильтрами, и всем остальным всем, что было до. Вы спросите, а что же ты йода втираешь дичь. Типа. вот ты там решил потом не решил, потом опять справил и опять нет. Ну вот такой вот я Йода, который не может предусмотреть все. Но если вы не хейтор, а вам интересно что же это было и как исправилось. То я вам расскажу, и это очень смешно: Помните мы убрали фильтр? А помните, по страницам фильтра боты ходили? А теперь они увидели там 404, и что? Да пошли с утроенной силой чтобы проверить весь ресурс. На всю эту прорву мусороного контента, который был в очереди на сканирование. И был уже проиндексирован! Просто всего ничего к нам зашло за день и только на html контент (обращения к статике в логе не учитываются): Удивительно, чо же там с нагрузкой. Ну ладно. Но у нас же проблема. Боты приходят на чпу ссылки. У нас нет хвоста site.com/filterviewer/какаятотупаястраницафильтра. Так бы мы могли спокойно в nginx-конфиге заблочить сразу это все в 404 на корню и забыть про проблему. Ок. Смотрим, что у нас есть в ссылках, а у нас там есть ~ в ссылках вида 023~500-031621~sp0720-8003-ts~500-0702701~500-0702702~2140-180~2141-228~2516-240~4152-250~4155-213~kr2300-205~tstr6-762ef~500-031616. Проверяем таблицу url_alias, там у нас символа ~ нету. Волшебно, БИНГО. Через минуту после блокировки всех ссылок с таким признаком на уровне web-сервера, наша нагрузка пришла в норму и проект зажил ровно так как и должен работать, зарабатывая владельцу деньги а не геморрой и седые волосы. Нам еще много предстоит сделать, чтобы гадкий утенок превратился в красивого лебедя. Но эта моя сказочка про конкретную историю, как бывает когда два неграмотных дополнения могут привести к остановке бизнеса на пару недель, и про то что не всегда стоит бежать покупать стопятидесятиядерные сервера, так как не разобравшись в корне проблем, решить вопрос железом может быть или слишком дорого или невозможно в принципе. UPD: прошли сутки и у нас новое бинго 657 мать его тысяч запросов от гугл бота.. Как это развидеть! Viiver ты что курил, прежде чем написать этот бред? Как тебя выпустили, я не знаю откуда, но людям тебя нельзя показывать!

Ну сэм восэм! Это последняя миля, скажем так.

CDN для статики, решает чуть баллов при оценке pagespeed, потому что уменьшается количество обращений на базовый хост. А все остальные вопросы - как были так и остались!

Тут есть такая штукааа... Чтобы CDN нормально работал и не закосячил вам страницу - его долго надо учить!

А с чего там им вырасти? Разве там написано: используйте cdn и получите 1000 баллов?

1 так, и да нужно. 2 посмотрите по аналогии с session или db. Как инициализируется экземпляр класса, и как получить доступ к внешним ресурсам.

C разрешения владельца магазина, позволю себе, рассказать вам чудесную историю, про то какие бывают модулепейсатели, оптимизаторы, почему они кровососы, и что с ними делать, думаю, что растянем на несколько частей, потому что в рамках одного поста не вместится. Так исторически сложилось, что я дружу с владельцами и инженерами некоторых хостеров. Неделю назад, ко мне обратился ведущий инженер крупного белорусского хостера с вопросом, у нас тут у клиента перегруз по всем лимитам 600%, как ему помочь? Ответ был - никак. Просто при первом же осмотре, в магазине обнаружился filter biber и вот эти все его недосео посадочные страницы. Как говорят создатели сериала "настоящий детектив" по просьбе выживших мы не приводим домен магазина. Но когда проект перенесли на хороший VPS с 5 гигагерцовыми процессорами, магазин показывал вот такую нагрузку: После того, как ваш покорный слуга сделал волшебные магические пассы, у нас стало так: Мы снизили потребление процессорных ресурсов в десять раз. А потребление памяти в текущей конфигурации - величина постоянная, так как ее в основном жрет php-fpm и в режиме ondemand делает это не больше и не меньше. И самое главное. Ну у нас две самых главных вещи. Во первых мы пустили ботов не на псевдосеомусорстраницы, а на нормальный контент, и уменьшили экстремально время ответа сервера на холодную без кешей, джет кешей, а для простого обычного пользователя в три-четыре раза. Как это происходило, что мы сделали, почему фильтр бибер, джет кеши и лайтнинги - это дикое зло. В следующей серии. В дополнение, хочу заметить, между этими двумя графиками два дня и семь лет. Два дня мы это сделали. Семь лет, приходило понимание как это сделать!

А вы уже прошли верификацию на форуме? И вы уверенны, что @chukcha чист на руку. По моей информации этот как вы говорите "авторитетный разработчик" продает бесплатный код сборки как свой. И участвует во вражеских коммьюнити, как активный контрибьютор. Такой знаете.... И рыбку скушать и присесть удобно на большое и толстое. Волк в овечье шкуре. Мне кажется, все что он может сделать - просто извинится перед сообществом за свои мелкие проделки. И поверьте. Авторитета там ноль! Его даже в техникум не взяли! В ТЕХНИКУМ!!! Вдумайтесь.

С - семгентация. Ой, а что тут у нас ? ?rdrf[attr][13][]=силикон Redream фильтр. А у него там свой кеш, а там скорее под 10к файлов. А еще этот фильтр никуда не годится под большие магазины. Ну и в целом все что выше написали. Если спросите почему - ответ потому что скорее всего вы не являетесь специалистом в реляционных базах данных и пытаться объяснять, почему выборка, группировка и подсчет уникальным значениям полнотекстовых полей в реляционной модели организации данных - это утопия.

Нету таких пакетов. Регулярно сталкиваюсь с подобными проблемами. Решается в целом все успешно. Но не всегда в лоб. Смотрите в сторону анализа характеристик паразитных запросов. Там всегда будут аномалии. Смоделировать идеальные нативные посещения практически невозможно. А уже по признакам стройте правила и реагируйте. Реакция кстати может быть очень разная. От редиректа паразитного трафика на порнхаб до простого отключения аналитики и метрики в вашем случае. Говорить про просадку вот прямо от странного трафика. Это вилами по воде. Скорее всего она у вас от медленного ответа сервера в момент атак. А не от того что поисковики увидели аномальное поведение. Так как в целом оценка поведенческих показателей происходит изначально на уровне. Нашёл в поисковике, зашёл и дальше не пошёл. А уже потом по поведению на сайте. Если у вас прямые заходы, тем более без загрузки js скорее всего, они вряд-ли могут повлиять на ранжирование.

Ну давайте со всего интернета мусор ташить и рассказывать про курилку! Бред жеж!

Дружище, ну форум тут при чем... Ну это же не канал Интер, где надо жаловаться в передаче про мошенников, как тебя циганка обвела вокруг пальца!

Да подсунул Шелл ваш товарищ куда-то и все. Решается как два плюсе два без поиска дыр. Ну и поиск дыр, тоже решается анализом логов.

А то что летом, когда сняли ограничения массово, он еще больше взлетел вас не смущает? И то, что основной рост произошел в момент, когда про карантин никто не слышал, а covid был где-то там далеко ?

Тоесть таки да? слова на скрине твои? Не отрицаешь?