Пока это мой тренд для дальнейшего вещания. Реализуется он или нет, зависит не от меня.

В уходящем году, вряд ли я что-то могу сказать позитивное или хорошее, кроме того что русне дали МЗДЫ)))
И это не заслуга президента, доноров из-за рубежа, а заслуга исключительно spirit of ukrainian people!

Нация, мова, вира, армия, церква, перемога. Цели и задачи. Все это мелочь.

Мы все победили! Все кто остался, все кто работал под обстерлами, бомбежкой, кто вернулся, кто не сбежал как последняя падаль за 5000 долларов как инвалид в америку.
Кто был рядом, кто поддерживал, помогал, отдавал последнее, восставал из пепла после очередной контузии, верил в ближнего, в перемогу, в добро. 
Донатил, волонтерил, спас семью, покормил чужого кота.

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

Наверное мы все стали лучше, чище, честнее. Не могу утверждать однозначно. Время покажет, но это большой экспириенс, и скорее всего неизбежный.

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

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

А потом у и у наших детей и внуков, на много много лет будет мирное небо, и эти нелюди забудут что такое, ходить сюда с оружием!

Мирного 2023 года, успешного бизнеса и п@зда русне!

HAPPY 2023!

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

Вводные данные: магазин на клауд сервере на хецнере. С какой то там брейни панелью ублюдочной, и этот сервер ни в какую не хочет отправлять почту ни черезе mail ни через smtp.

Копей специалисты сломали вагон.

Делали что угодно, но не выходил каменный цветок.
В итоге папа добрался до этого кейса. Настроил PTR DKIM DMARK SPF, прописали корректный hostname, но почта не пошла.

Залезли мы в логи и видим 

Connection timed out H=reception.mail-tester.com

Странная петрушка. Начинаем копать, делаем telnet на любой почтовый сервер на 25 порт и получаем connection timeout.

Отключаем все: firewall, iptables, sellinux. Все все службы которые могут блокировать исходящие соединения на 25 порт. ИИИИИИИИ...

И нифига. такой же таймаут. 

Начинаем гуглить, и где то в треде реддита находим историю про блокировку хетцнером на клаудах исходящих почтовых портов со спамом они боряться... 
Да ну ладно ?

Идем на хетцнер в документацию....

https://docs.hetzner.com/cloud/servers/faq/#why-can-i-not-send-any-mails-from-my-server

ШТАА ?????

Я честно говоря выпал в осадок....

Т.е. вот вам сервер, но почты на нем нет не будет, и нигде про это не написано явно, если очень сильно не напрячься и не нагуглить....

Ну как так....

Вот тебе друг машина - но без двигателя, а двигатель по запросу, а ты еще расскажи зачем тебе он нужен....

Занавес. Все остальное, что могу сказать - только нецензурная лексика....

В итоге да, мы  отправили запрос, да с какого-то раза нам открыли порты, почта пошла. Но это трындец!

Также если вам надо съехать с оккупантских хостингов, что-то донастроить, что то не работает, и в совсем критичных ситуациях, когда нет денег на оплату хостинга, у меня есть определенные возможности вам помочь.

ПОЖАЛУЙСТА НЕ ОБРАЩАЙТЕСЬ С ВОПРОСАМИ, СДЕЛАТЬ МАГАЗИН, НАСТРОИТЬ СЕО, И С КАКИМ-ТО ИНЫМ БРЕДОМ, БУДЕТЕ ПОСЛАНЫ ЗА БОЕВЫМ РОССИЙСКИМ КОРАБЛЕМ. ТОЛЬКО РЕШЕНИЕ ЭКСТРЕННЫХ ПРОБЛЕМ И НЕПОЛАДОК!!!

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

Так как при инициализации адимнского раздела, движок все равно делает сто пицот обращений в базу и поднимает php-потоки, получается приличная нагрузка на сервер.

Защитится - как два пальца об асфальт.

ПОЖАЛУЙСТА! СДЕЛАЙТЕ ЭТО СЕБЕ ВСЕ.

Вам прсото достаточно закрыть админку под htpass.
Если у вас апач  - инструкция здесь: https://htmlweb.ru/service/htpasswd.php

Если nginx здесь: https://docs.nginx.com/nginx/admin-guide/security-controls/configuring-http-basic-authentication/

Если у вас ISP панель, сделайте ограничение для папки админ. Инструкция здесь https://docs.ispsystem.ru/ispmanager6-lite/www-domeny-sajty/ogranichenie-dostupa-k-sajtu

UPD: вот такая идиллия восстановлена после суток лежачего магазина.

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

Я не знаю кто первый это придумал, но сталкиваюсь я с подобным тезисом, на каждом шагу. И очень часто я вижу купленные ненужные дорогие ресурсы, которые просто стоят мертвым грузом

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

Второй миф. Когда на магазин приходит нагрузка от ботов, или парсинг, или школьный ддос, да просто предновогодний трафик в конце концов, часто густо сервера начинают падать, глючить, приходит какой-то мего спец с умным видом говорит - "у вас ДДОС", срочно срочно надо уходить под cloudflare, ddosguard или stormwall.

Перед новым годом, ничего не предвещало неожиданностей. Меня попросили посмотреть один проект, и через 10 минут после вникания в ситуацию, у меня начал судорожно дергаться глазик.

Вводные данные: 10к товаров, 3к трафика в день, выделенный сервер на бегет. не VPS а именно дедик за 10 000 рублей в месяц, а также платный пакет stormall за 15000. При этом занято на диске 400 из 500 гигабайт, и магазин работает несколько нестабильно. 

А теперь небольшая калькуляция (10000 + 15000)  * 12 = 300 000 рублей в год за инфраструктуру.

По итогу после приведения в порядок магазина, отказа от бесполезного stormwall (если надо будет - есть CloudFlare за $20 в месяц), переезда на нормальный VPS за 2000 рублей в месяц и аренды еще пары сервисов по мелочи, мы в 2022 году сэкономим порядка 250 000 рублей чистыми. 

Вы опять же спросите - как так? Почему мелкий VPS оказался производительнее чем выделенный сервер?

Да потому что за 10 000рэ на бегете был какой то xeon лохматого 15-го года выпуска, древний измученный ssd, и DDR3, а взамен мы арендовали 3 четырехгиговых ядра, nvme диск, и DDR4, что позволило почти на порядок увеличить моментальную скорость генерации страниц.
Также у вас может быть хоть  150 ядер и 100гб памяти, но если у вас в настройках базы данных к примеру стоит 100 max_connection, то все ваши ресурсы просто будут греть воздух, ну или как сервиз для красоты в серванте стоять. Ну кроме настроек базы - есть еще несколько затычек в дефолтных настройках стека LAMP, но если их все перечислять - это на пару десятков постов потянет. Так что просто поднастроили все как надо.

Вы спросите, а куда же ты Йода дел 400 гигабайт, ведь не может стоить 2000 рублей с таким количеством места VPS?

Конечно же дел, вынес бекапы на внешнее удаленное хранилище, почистил логи (200 гиг было), добавил архивацию свежих логов, удалил старые базы, хламушник от обмена с 1с, и 400 гб отлично превратились в 37гб.  

Также, напрашивается вопрос. А что же с трафиком, как может мелкий VPS в 3 ядра работать успешней чем многоядерный собственный процессор?

И здесь все тоже очень просто. Во первых магазин как и автомобиль, требует профилактики и тюнинга, очень часто бывает удается сделать из 2-3 секунд 200-300 мс. Но в целом даже пятикратный прирост скорости генерации страниц, который мы получили на этом проекте, за счет настройки магазина, более чем достаточен, чтобы мы вписывались в 30-40% от пиковой нагрузки сервера. Во вторых: боты боты боты боты! Смотрите в логи друзья, там часто ходит такой зоопарк, что вы даже себе представить не можете, мало того этот зоопарк может ходить туда куда ему не надо, равно как и гугл и яндекс боты. Если ограничить доступ к магазину для всяких MJ12, Petal ботов и т.д. И закрыть в роботс корректно ненужные страницы для легитимных ботов, то и еще нагрузку на систему можно снизить на 40-50-70%. Ну а 3-4 к трафика в день с глубиной 5-6 страниц человека, для нормального VPS - это детский лепет. Пошло как дети в школу.

И еще логичный вопрос от обывателей: а почему бы не поставить джет кеш или лайтнинг, ведь они ускоряют ?

Очень хочется увидеть как они ускоряют агрегатный запросы в админке при обработке 4-5 сотен заказов в день. Ну или как они ускоряют внутренний поиск на сайте.
В данном случае пришлось потратить пару дней для скурпулезной простановки составных индексов, под запросы моделей, которые в админке обрабатывают данные о продажах.
Так как в сложных JOINах с таблицами по 300-800к строк, просто так нельзя взять и взять проставить индексы на id, и думать что поможет!

Ну и поиск sphinx быстрее любых потенциальных аналогов.

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

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

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

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

Также спасибо моим друзьям @SooR, @29aleksey, @Exploits, @spectre, @nikifalex. Мы с вами сделали очень много классных быстрых и успешых проектов и помогли доброй сотне владельцев магазинов улучшиться в прибылях.

Желаю от души всем хорошим вменяемым людям в следующем году улучшится в их бизнесе в 2-2.5 раза.

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

Встретимся в 2022, ваш Магистр!

Ну подумаешь бывает, школьники балуются. Добавляем ресурсы php-fpm для этого товарища, включаем кеш html страниц магазина (модуль турбо), включаем nginx базовую защиту от атак https://www.nginx.com/blog/mitigating-ddos-attacks-with-nginx-and-nginx-plus/, и  спокойно возвращаюсь к мясу и пиву с чувством выполненного долга и ощущением, что этот тупой малолетка, может дальше ддосить сколько угодно. И вроде бы было все ок, если бы в понедельник, опять я не получил оборванный телефон и скрины в телеграм такого толка:

Кароче привет 90ые, нас поставили типа на счетчик. Ну и да реально выделенный сервер, не ВПС на 8 ядер и 64гб памяти лежит и валяется.
При попытке перезагрузить сервисы, они зависали тут же. 

Тут мне стало очень интересно.
У меня достаточно большой опыт борьбы с подобными товарищами, но вот этот оказался очень активный и агрессивный.
Нашел магазин, у которого специфика ассортимента, когда декабрь перед новым годом, за месяц год кормит, купил ботнет и решил заработать деньжат. 200 + 30 в час - это за сутки 200 + 720 - фактически 1000 долларов, и не будь меня за спиной у нашего потерпевшего магазина, он бы их и заплатил, так как потери несопоставимы, и ведь неизвестно сколько это может длиться.

Вот вам небольшая статистика за сутки про мощность атаки:

Всего-навсего полмиллиарда запросов на веб сервер за сутки!

В пик у нас было:

28м запросов на сервер в 15 минут, у есть подозрение, что в гугл столько запросов со всей Украины не приходит за 15 минут.
 

Но мы чудесным образом и отбились, и еще отбили интерес у нашего школьника решившего подзаработать лезть к магазину моего товарища.

А теперь пошаговый алгоритм что было сделано.
 

1 - у меня есть свой скрипт антиддоса, аналогов на гитхабе миллион, ловим всплески за разные периоды времени и блочим айпи. На какой-то период этого хватает, чтобы магазин работал хоть как-то.

2 - Добавляем для вируталхоста новый не засвеченный в мир айпи. Это важно, так как атакующая сторона может работать в обход днс и слать запросы прямо на сервер с нужными заголовками.

3 - Уходим сразу очень быстро под CloudFlare, прячем новый айпи за прокси CF, и проксируем реальные айпи в php магазина и по прежнем продолжаем блочить входящие запросы.

4 - Пока меняются DNS мы не можем закрыть старый айпи, поэтому терпим, но CF направляем на новый и блочим на новом на уровне сервера любые прямые запросы кроме подсетей CloudFlare ну и там всяких офисных, сервисных и  домашних айпишников.

5 - Как только http://host-tracker.ru/ показал, что процентов 90 ресурсов из мира видят сайт на ресурсах CLoudFlare блочим старый айпи, при чем желательно на уровне firewall провайдера хостинга, в нашем случае это Hetzner - там есть какой никакой файрвол работающий на уровне их сети и это просто.

6 - Пока идет вся эта котовасия у нас уже куплен платный аккаунт CloudFlare, который позволяет создавать правила для внутреннего файрвола. Первое созданное правило - заблокировать все страны кроме Украины и известных ботов. Еще было штук 10 правил - но они вторичны.

7 - Включаем в CloudFlare максимальный уровень реакции на DDOS, никаких капч никакой фигни. Только блок и все.

8 - Запасаемся попкорном и ждем пока наш упырь-мамкин-ддосер докупает и докупает еще и еще мощностей ботнета, и нифига не получается.

В конечном итоге я еще внимательней посмотрел в логи, нашел в них ошибки в серверных заголовках и с вероятностью 99.9%  закрыл все обращения нашего парня. Он мог бы купить в 10 раз больше ресурсов, но с таким уровнем подготовки, все равно ничего бы не добился.

К чему эта вся статья. 

Ну во первых я хвастаюсь, с момента возникновения критичных проблем с этим инцидентом, до момента решения, прошло всего порядка полутора часов (правда мониторил я его без сна потом почти сутки).

Во вторых. И это пожалуй самое важное. НИКОГДА НЕ ТОРГУЙТЕСЬ С ТЕРРОРИСТАМИ. 

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

Также вы должны знать, что смоделировать идеальный ддос и естественный нативный трафик очень и очень и очень сложно, практически всегда специалист найдет какой-то признак, по которому можно душить паразитные запросы.

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

Вот такая вам новогодняя сказочка.

Дальше больше!

UPD1: Запомните, сравнивать бесплатный Cloudflare, который просто может проксировать ваш трафик и спрятать айпи и платные пакеты - это как сравнивать одноногую косоглазую Бритни Спирс с молодой Памелой  Андерсон. Вобщем бесплатный сервис CloudFlare  - это просто ничего, и как бы вам не рассказывали тупые саппорты хостеров и специалисты начального уровня с форума и фриланса, он вам НИЧЕМ НЕ ПОМОЖЕТ в случае ддоса!

UPD2: Пишу я этот текст не для того, чтобы при любой проблеме вы бежали ко мне, скорее всего если вы придете с улицы с просьбой помочь вы получите отказ. В последнее время очень сильно активизировались различные менеджеры среднего звена и любите поклевать мозг холостыми разговорами. В связи с этим, без рекомендаций от моих друзей или уважаемых участников сообщества, я практически не иду на контакт по каким-либо реализациям. Да я опух, потерял берега, цены себе не могу сложить и так далее, вобщем, называйте как хотите, мне все равно.
Данный пост имеет исключительно общеобразовательную миссию, и не является коммерческим предложением или иной рекламой тех или иных моих реализаций!

UPD3: Вы спросите - а что нам делать - у нас шаред хостинг за три копейки? Ну тут друзья - я вам не виноват что у вас в 2021 году шаред хостинг, во вторых, очень быстро можно купить какой-нибудь cloud сервер или на хетцнере или на digital ocean, сделать его публичным прокси вашего магазина, скрыть его за CloudFlare и с точно таким же цинизмом, как имея выделенный наблюдать, как корчатся в конвульсиях мамкины ддосеры. Чуть дольше на час-два, но никааааааааких проблем!

#!/bin/bash
a=$(redis-cli -p 6379 PING) 
if [ "$a" != "PONG" ]; then
    b=$(systemctl start redis)
    echo $b
fi

Добавляем в крон и радумеся!

Вот например:

Или

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

Но все же. Вернемся к нашему герою и нашему магазину......
Без Регины и идиотов............

В чате форума есть такой тип EvgSmr, он же @t7p на форуме. 

И уже где-то с полгода, наш герой жалуется, что вот мол кешеры не очень, у меня вот магаз в 100 мс, и я хочу быстрее, но карточки товара в 500 мс, а я не хочу прогревать кеш, чтобы отдавать как говорит маэстро @SooR .html

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

Что мы поулчили. Главная страница +-100 мс, категории +-200 мс и ооочень долго в его понимании (да он ваще охренел) 500 мс карточки товара.

Когда мы сделали индексацию базы, настройку веб сервера, приведение в порядок всех параметров окружения мы полчили даже иногода 60 мс на главной, но все равно долгууууую карточку товара.

Заупустив профайлер mysql запросов, мы получили

0.05 мс запросы и вопрос явно был не в них.

И до момента, когда у нас карточка товара уходила на $this->response->setOutput все было отлично

и наши 50-60-80 мс были доступны и реализуемы.

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

Ок мы локализовали, что у нас проблема в шаблоне, пошли его резать и нашли в унишопе по моему, такую вот фигню:

<?php echo @number_format($mpn, 2, '.', ''); ?>

Вот эта одна конструкция убивала все наши оптимайзы.........
Оказалось что в 7.3 php , нельзя просто взять и взять для функции number_format  прислать пустой аргумент, или текстовый аргумент, он должен быть хотя бы float.
И оказалось что когда php обрабатывает такую ошибку, оно ахренеть тупит, а у нас тут вызов функции с ухом был, которое все ошибки прятало, и ....

Вобщем ухо прятало ошибки, их никто не видел, карточка товара тупила, мы потратили 8 часов на поиски этой фигни, и как только мы сделали нормальный обработчик входящим данным переменной $mpn вида

<?php  if($mpn) { ?>
      <span><?php echo number_format((float)$mpn, 2, '.', ''); ?></span>
<?php } ?>

У нас сразу все страницы товаров стали открываться до 100 мс.

Знаете, когда мы это все решили, у меня был один вопрос - а что так бывает? А что так можно было? И а какой же ты  Джигурда автор кода с ухом, который такое сотворил.



Я не умаляю общих действий и заслуг владельца проекта, и моих. Но екалемене, вы когда пишите код, думайте пожалуйста головой.
У нас тут выделенный сервер, абсолютно оптимизированный движок,  50-100мс до секунды без кешей, и у нас прилетает вот такое вот бредовое ***но...



Ну имейте же совесть. Прошлый пост мой, он специально был хайповый. На него поймалась очередная порция жертв "переписи идиотов сообщества".
Но для всех вменяемых, пожалуйста, тестируйте ваш код в боевых условиях. Не делайте ухо!!!!

Ну и в целом если @t7p наберется храбости, он вам расскажет как у него было долго нудно, как ему вставили рога марк и лайтнинг, и как у него получилось теперь, его и моими молитвами....

Ждите продолжение!

@t7p вроде бы согласился от первого лица описать все мытарства, которые он прошел на пути достижения дзена. От тупого магазина до проекта, который отдает динамические страницы без кеша за 70-120 мс. 

0.  И это самое главное 

https://search.google.com/search-console и https://webmaster.yandex.ru/

Это наше все! Карты сайта, ошибки, дубли и всю перхоть мы можем отловить здесь! 

1. https://www.host-tracker.com/ru/

На вопрос "у меня лег сайт" мы всегда смотрим в host-tracker.

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

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

2. https://www.mail-tester.com/

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

3. https://www.dnsbl.info/

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

4. https://developers.google.com/speed/pagespeed/insights/?hl=ru

Тот самый страшный пейдж спид от гугла. Единственное средство, которое можно принимать во внимание оценки качества и скорости вашего проекта.
Никаких богомерзких gmetrix.

5. https://googlechrome.github.io/lighthouse/scorecalc/

Калькулятор lighthouse - полезная штука, когда надо понимать чем надо жертвовать и стоит ли, ради попугаев pagespeed

6. https://webmaster.yandex.ru/tools/server-response/

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

7. https://xenus-link-sleuth.softonic.ru/

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

8. https://netpeaksoftware.com/ru/

Платное распиаренное дерьмо, но если он у вас есть,  лишним не будет, делает то же самое что и Xenu, только за деньги и еще показывает там какие-то фичи.

9. https://www.cy-pr.com/ и https://pr-cy.ru/  
В целом такие себе сео анализаторы, но какую то базовую информацию можно из них получить.

10. https://topvisor.com/ru/

Лучший сервис для снятия позиций ваших магазинов. Достаточно дорогой, но с замечательным интерфейсом.

11. https://mxtoolbox.com/ 

Это ваще отрыв башки, если вам надо протестировать корректность ваших любых DNS записей - вам сюда.

12. https://developers.google.com/speed/public-dns/cache

Сброс кеша гугл днс. Когда переносите магазин с сервера на сервер - маст хев, кеш сбросили, и все пошло быстрее переносится по всем дочерним днсам.

13.  https://1.1.1.1/purge-cache/

Такой же сервис как и для google, только для cloudflare.
Хотите быстрый перенос все ваших записей - используйте оба два при переносе.

14. https://search.google.com/test/mobile-friendly?hl=ru

Проверка ваших страниц для мобильных от гугла, seach-console показывает не все и неявно - здесь можете посмотреть, как гугл-бот видит  ваш магазин.

upd:

15. https://xtool.ru/

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

16 приблуда от @Nameless

https://technicalseo.com/tools/

Какое то пендосское разводящее дно, но может кому будет полезным

17. https://validator.w3.org/ 

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

Если что еще вспомню, дополню!

Быстрых вам магазинов!

Но тут я обнаружил пару процессов, про которые я просто не могу не написать.

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

ИИИИ тушит ваши магазины.

Я не буду долго развозить, просто покажу скрин:

Пришел ко мне соучастник и говорит вот такие у меня проблемы что делать.. Сайт просел в выдаче и полный капут.

Ну конечно капут,

Реально нет даже ни малейшего желания заниматься разбором полетов откуда эти дубли пролезли в выдачу.
Но когда они пролезли у человека просело -50% трафика.

Спасибо тебе максд - ты крутой программист, кроме тебя сайты может укладывать только маркимарк.

А теперь про маркимарка.

Вчера, один наш товарищ показал вот такой график:

Да, вам не показалось - это 12,5к хостов органики из гугла в день!

И у нас был простой диалог:

Цитата

Magister Yoda, [15.09.21 20:27]
Так как ты

Magister Yoda, [15.09.21 20:27]
Такое учудил?

Владелец магазина, [15.09.21 20:36]
Что учудил?

Magister Yoda, [15.09.21 20:38]
трафик

Владелец магазина, [15.09.21 20:38]
Блог *****

Владелец магазина, [15.09.21 20:39]
Сначала весь мусор удалил

Владелец магазина, [15.09.21 20:39]
Статьи крутые пишем

Владелец магазина, [15.09.21 20:39]
Перелинковка

Владелец магазина, [15.09.21 20:40]
Ссылочную массу чуток прокачал

Magister Yoda, [15.09.21 20:40]
[In reply to Владелец магазина]
я думаю что это самое важное

Владелец магазина, [15.09.21 20:40]
Не

Владелец магазина, [15.09.21 20:40]
Я на блог не закупаю ссылки

Владелец магазина, [15.09.21 20:41]
Изначально от ****** отказался

Magister Yoda, [15.09.21 20:41]
в статью график можно твой взять ?

Владелец магазина, [15.09.21 20:42]
конечно

Владелец магазина, [15.09.21 20:43]
пускай народ знает, что на опенкарте можно космос делать)))

 

Выводы делайте сами!

https://rc-like.ru/

И заглянув в исходный код нашел там волшебную магию прямой кишки:

Друзья, этот юноша @markimax реально просто берет и тащит на себя с вас ссылки, а вы даже об этом не догадываетесь!

А потом у вас плохое сео  и вот это вот все...

По моему это ваще на фиг за гранью!

Блин блин блин, 10 000 магазинов выбрали дополнения?

Более 10 000 магазинов выбрали дополнения этого недочеловека, чтобы быть ссылочными донорами для его сайта!
Круто же!!!
Продолжайте в том же духе...

Как там говорил @dinox ?

Сделаем сообщество лучше?

Лучше для маркимарка ?

Последние две недели.
Приходит мой друг говорит у меня тут все ложиться, клиенты не могут заказ оформить, база падает!

Смотрим. Ну ежкалемене на магазин на 200 товаров филтер бибер

И у него 100 000 запросов от гугла в сутки на страницы этого бреда!

Вот эта хламина!!!

Надробила ему полмиллиона ссылок. С ноиндекс без ноиндекс.
Но это бред.

Слава богу что друг мой на turbohost и @dinox выдал с барскго плеча временно достаточно ресурсов, чтобы это пережить.

Хвала тебе конотопский герой. Что ты поверил в коня и замироточил...

Мы реально уже пятый день, ловим 100-200 к запросов на эти все посадочные фильтра от бибера.

Это бред. Бредовый бред делат посадочные все со всеми.

Мораль - бегите от фильтра бибера, пожалуйста..

Есть вменяемый же 

Ну или

Но друзья, никогда. Прошу вас, никогда ********** filter_viewer, это такая ******** мать**** **ка *** на **й странная вещь!
Я не знаю чем думал этот перс, который ее написал!

История номер два, которая зацепила до слез, есть у нас такой странный тип @toporchillo, у которого есть модуль для беру ру обмена инфой, и он такой этот усатый типа супер программист и так далее...

Но блин этот усатый таракан программист живет в каких то 90х и у него везде апач, а  у моих красавчиков у всех nginx.

И он такой - ой. А я вот тут что то написал, а как запустить под nginx это не знаю, и это ваши проблемы.

Друзья мои.. Если вы столкнетесь с этим товарищем, то вот вам решение для nginx под его модули для маркетплейса беру ru

в конфиг nginx добавляем перед location /

       location /yandexbuy2/ {
            proxy_hide_header Content-Type;
            add_header 'Content-Type' 'application/json charset=UTF-8';
            rewrite ^/yandexbuy2/(.+)$ /index.php?route=yandexbuy2/$1 last; 
           
        }

       location /yandexbuy/ {
            proxy_hide_header Content-Type;
            add_header 'Content-Type' 'application/json charset=UTF-8';
            rewrite ^/yandexbuy/(.+)$ /index.php?route=yandexbuy/$1 last; 
            
        }

И в сеопро в метод validate добавляем

    if (isset($this->request->get['route']) && stristr($this->request->get['route'], 'yandexbuy')) {
            return;
        }

   Знаете, для меня до сих пор загадка, почему этот персонаж, который вроде не тупой совсем програмист, не умеет делать такие простые реализации..
Но если он придет и скажет спасибо за то что мне оплатили за его работу, мне будет приятно!

Ну и @pikitos пробил дно.

$sql .= " ORDER BY nalichie2 DESC, nalichie DESC,

Видимо он когда упал с мотоцикла в Тайланде, у него что-то совсем  щелкнуло в голове.
Мало того что у него был один раз запрос с сортировкой по предварительно вычисляемому полю, ну он еще их решил сделать два.

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

У меня еще есть для вас много историй и кейсов. Но пока нет настроения их расписывать.

p.s.

Чуть не забыл.

Для тех кто на 1.5 и не только, но юзает это допотопное решение.

Пожалуйста, бегите от этого... Вот прямо сейчас.
Ибо эта дрянь делает полную перезагрузку DOM после инициализации любой страницы категории и это CLS секунда-полторы, а гугл пейдж спид, очень не любит это дело...

Просто потратьте 2-3-4к рублей и смените это морально устаревшее ***но мамонта на что-то внятно и современное!

Это ужасно, ужасно ужасно  в рамках поддержки платного дополнения, которое только разводит и не делает результат!

Но мы же с вами грамотные красавчики. И мы  понимаем что волшебной таблетки не может быть!

Но нам гуглпейдж спид кажить все эти FCP CLS и весь этот бред типа.

Друзья. ни один модуль не решит ваши проблемы.

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

Но ок, что же нам делать, у нас есть рабочий интернет-магазин. мы хотим подтянуть позиции по выдаче и стоим на распутье, хотим быстрый First contetn paintfull и отсутствие Cumulative Layout Shift.

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

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

1. Все изображения во всех модулях, списках, баннерах и так далее идут в Lazy, просто берете и делаете нативное Lazy 

https://developer.mozilla.org/ru/docs/Web/Performance/Lazy_loading

Просто добавляете к изображениям свойство loading="lazy"

2. все изображения переводите в webp, для этого не надо бежать к сайткиратору и покупать платный модуль, просто пользуете это:

3. В большинстве шаблонов у нас по умолчанию в верстке list, который потом через js переводится в grid, сделайте grid в верстке по умолчанию и это отличн вам решит CLS показатель, так как у вас не будет сдвига макета при рендере, если не знаете что это и не знаете как сделать - долбите авторов шаблонов.

4. Новые хотелки page speed хотят, чтобы skeleton разметки страницы был сразу с установленными параметрами размеров изображений. Если у вас единый размер, задайте во всех выводах изображений width и height принудительно.

5. Используйте современные шаблоны. Да я верю, что вы все положили много денег и ресурсов в то что у вас есть, но

или 

Криво косо, но содержат в себе какие-то built in механизмы отпимизации-сжатия скриптов стилей и дадут вам меньше запросов на вебсервер.

Несмотря на кривость реализации, это лучше чем ничего!

А еще шаблон от @29aleksey все таки прилично выглядит по сравнению со всеми остальными поделками за полтосик.
Мне бы в 2012 году такой, для моих магазинов. Реально Леха-кравачик и душу вложил! 

6. Если вам вот прямо необходим JivoChat, 

Вот вам отличный мануал, как решить с  ним проблему;

https://habr.com/ru/post/447262/

7. Да я молчу про TTFB, который тоже влияет на оценку pagespeed, да я знаю как это сделать, да, я с удовольствием сделал бы  бесплатную таблетку, которая решала проблему быстрой загрузки HTML контента, но это не возможно к сожалению, Минимум что я вам могу рекомендовать, едьте на быстрые хостинги, пользуйте пхп 7+, следите за включенным opcache.

8. Если  у вас там метрики  и аналитика от гугла - снести все в футер, это плохой совет, возможно вы лишитесь 3-5% каких то показателей, но зато внешние скрипты не затупят.

9. если у вас модуль доставки типа сдэка - посмотрите, чтобы он не пытался грузить яндекс карты на все страницы магазина.

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

11. Счетчики, аналитики и т.д. Ни в коем случае не делайте их подгрузку по пользовательскому событию или в отложенную загрузку. Уж если сильно вам мозолит глаза 10-15 баллов, которые они навешивают, снесите их  в футер.

12. Вывод и скрытие контента в зависимости от типа устройства. Используйте с умом. Пользуйтесь не js библиотеками а mobiledetect, от того что вы спрячете в display none какой либо элемент, он все равно будет опубликован в DOM страницы, если что-то хотите убрать для мобильных устройств, просто не выводите этот контент фактически при генерации html кода!

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

upd: ну и еще банальшина, но проверяйте настройки кеширования сжатия статики, и если у вас webp то и для него добавляйте правильные заголовки.

К примеру, если у вас ISP

то должно выглядеть так:

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

Опять же возвращаясь к ISP менеджеру, который заполонил все, попросите вашего вебмастера или саппорт хостинга проверить, чтобы nginx отдавал вот для этого всего правильные заголовки:

        location ~* ^.+\.(webp|jpg|jpeg|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar|flv|swf|woff2?|ico)$ {
            access_log off;
            expires max;
            break;
        }

Вот прямо можете давать ссыль на статью и говорить  - хочу вот так для вебп!

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

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

Идем в каталог дополнений и находим 

Ну красиво сверстано на демо - ок ок.

Мы же помним. наше все это поддержа, с @29aleksey я давно дружу и вопросов у нас нету по взаимодействию и новый магазин с нуля. и старый обновленный автор завел, просто как боженька, вот вы же знаете я всех чуть что хейтю. Но тут просто респект.

Ок. Нам дальше нужен фильтр....

идем и ставим 

Как два плюс два, все заводится, работает и поддержка божественна, может потому что опять же мы давно дружим с автором, а может потому что в принципе - не могу знать, по моему он делает супер саппорт всем...

Ок. 

И дальше маст хев 

Здрасьте уважаемый автор, поставьте пож и настройте, в ответ: вот вам пожалуйста все готово...

Ну да ну да, я там поразворачивал площадки, залил опынкарты, их оптимизирвал, сделал мегабыстрыми, создал фтп, обновил базы, но дальше - все реализации делали авторы и это просто великолепно...

А еще на одном магазине нам нужен был гугл мерчант фид от @spectre, так он тоже в три секунды встал настроен и работает. Вот без лишних вопросов и смс. 
Сегодня суббота. С четверга  я поднял три отличных магазина, которые завтра могут начинать продавать.

Я не знаю почему вы здесь все страдаете проблемами. Но @29aleksey, @SooR, @Exploits и @spectre просто на голом месте решили боли моих друзей.

Им спасибо, а всем вам рекомендую. Вжунь вжунь и готово - это к вот этим парням!

upd: очень хотелось бы написать такое же про @octemplates но у них реально слишком много дичи в коде, и они не могут в быстросаппорт. И по сравнению с их поделками, шаблон cyberstore - это космос Стас! Учитесь дети, как надо делать!
А еще если @29aleksey сделает скрипт миграции на его шаблон с мастером настроек - то просто откусит вам всем головы, шаблонопейсатели! 

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 мс. 

История первая.

Большой укр магазин, который торгует искусственными фаллосами и этим всем непотребством 3-5к хостов в день, но очень много гугл бота на богомерзкий фильтр бибер.
Переехал на бизнес хостинг на ukraine.com.ua, ничего не изменилось, лежит и не встает.
Стояло там все: джек плеш, лайтниниг, и только мешало своими file_get_contetn (много кеша) или select from oc_hlam_cache(name);
А если владелец запускает нет спик спайдер на фильтр бибер, магазин просто уходит в 502 и не оживает.
Ок.. Переносим на турбо впс на хост про, легче но регулярно ложится, 4 ядра все ввысь, никакого толку...

Ну. Ок. Ну тут у нас есть местный хостинг под опенкарт. И как бы я не относился к администрации форума, как бы они не исполняли. Я знаю, что хостинг правильный.
Решили попробовать. И о чудо МАЗАФАКА! На трех ядрах райзена, когда папа настроил все лимиты php-fpm и mysql мы смогли держать 400 одновременных запросов на магазин на трех ядрах. 

Очень много твиков, очень много настроек самого vps-сервера.  Но между -  дружище покупай свой сервер на хетцнере и диноксхостингом, оказалось что таки да. Можно сделать 120-150к pageview на трех ядрах, не уложив основной трафик магазина. Подчеркиваю. Это не на базовом движке, а на куче твиков и оптимизаций, как по движку так и по серверу, хост про такой же не смог!

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

Следующая история:
Я вот ща пишу, с радостью, потому что прошло 14 февраля и не единого разрыва. Ну вот как боженька пошептал, как самая сладенькая писечка.. Проект отработал наплыв трафика на ура!!

Большой локальный украинский бренд. Извините, у меня везде по умолчанию NDA и я не могу засветить домены, поэтому фантазируем: 10-15к хостов в день,  в праздники х2.
ВПС на 8 ядер и 16 гиг памяти.
Целая ахренеть фирма по поддержке хайлоад проектов на зарплате.
И все лежит. Лежит и не встает. 

Все ядра в топ!
А у них 14 февраля, через неделю,  и минимум время генерации 2 сек на страницу.

Студия которая ведет этот проект, мы с ними давно работаем, но я не связываюсь с прокладками. А предпочитаю общаться напрямую с владельцами - это минус нервы, но очень просили.
В итоге... Вы же помните, динкос-хостинг и это вот все... У нас уже есть реализация. Ок. ок.. Попросили большой впс, на 16 ядер, перенесли с 2 секунд сделали 300 мс, путем базовых твиков по движку и по серверу. Запустили нагрузочное тестирование в 400 смычков одновременно и получили 502 и ядра вверх.
Был вроде бы очень крутой проект с хорошей реализацией и тут 502.

Начали разбираться. И оказалось что наши герои просто куда то стучаться на geo-ip кокойтый API, который блочит при большом количестве заходов посетителей. Учитывая, что у нас шлюзы мобильных операторов не очень то и много разноообразные, понимаем что беда. 
Меняем сторонний сервер на free max-mind geo base.. И о чудо. Все работает.

Но не тут то было...

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

Начинаем разбираться, и находим что у моих друзей 10 фидов, которые они написали как отдельные php скрипты, т.е. просто в корне лежит facebook_feed.php там какой то mysqli_connect и потом он не закрывается. Крон раз в 15 минут, 10 фидов, wait_timeout в базе 28800, в итоге все эти фиды, просто как зубастики отожрали соединиение к базе.
И когда мы сделали все тюнячки по базе, закрыли вопрос со сторонним geo API, закрыли вопрос, с зкарытыми коннектами, настроили сервер. Моему счастью не было предела.
90% магазинов это ларьки. Этот проект - это мать его большой бизнес. 5 человек специалистов оптимизации говорили, что на опенкарде это невозможно, целая огоромная дорогая фирма (не буду говорить название, чтобы не обиделись) не смогла. Папа решил вопрос за два дня, спасибо тебе Динокс хостинг!

Вот сейчас ночь! 15 число. Мне никто ни разу не написал Хьюстон, у нас проблемы. Я последние три дня просыпался в 8 утра в холодном поту. А не случилось ли там что.
Я знаю что вам тут всем похрен, вам лишь бы бабки. Но бабок я могу вашими способами заработать доедренифени, у меня уже другие мотивации, и мне очень важно когда большие проекты взлетают и стабильно работают. Это такая медалька, орден. Типа. Йодыч, ты и это смог! Красава!

История третья.

Магазин на 90к товара.
Богомерзкий мега фильтр. плюс авары рабы туда свои хипер какую то перхоть всунули.  Лежит...

Старый мой давний товарищ, мы ему решали вопросы, когда было немного товаров но тут дохрена сталои фильтр про. И эти хиперкриворукие...

И парняга говорит простую вещь - у меня фильтр ведьмы, не кодированный.. Сделай мне сфинкс.
Сфинкс под фильтр ведьмы, реально кроме гансора я больше никому не буду делать, потому что он мне реальный друг. И это была индвидуальная акция, когда мы мега фильтр подружили на 1.5 м товаров.

Но что то же надо делать. У людей загрузка страницы без кеша фильтра 8 секунд. Главная 1.5.

Ок ок..
Переносим магазин на быстрый сервер админвпс, настраиваем лимиты сервера базы, настраиваем php-fpm.

Убираем из mega фильтра построение полного набора базовых опций  и встроеннго фильтра, получаем уже 4 секунды. Убираем джоины магазина, он у нас один, убираем date_available ву запросах. Уже легче..
где-то там 3.5-4 сек.

Идем в конфигурацию mysql сервера, разжимаем параметры  базы получаем 1.5-2. И тут видим богомерзкий мпн твик и сессии в базе, которые каждый раз очищаются.
И ЖРУТ 300 мс. Каждую  итерацию, каждый поток, у нас его автоудаление жрет 300-400-мс на каждой странице. Фак фак.  Решаем.. И ок получаем порядка 1сек..

Запускаем паук, и после того как мега фильтр наплодил кешей, вдруг у нас 2 секунды вместо одной.

смотрим в мегу. Помните же у нас открытый код:

а там какой то такой бред:

$time = (float) file_get_contents( $file_time );
    
 

    if( $time < time() ) {
      @ unlink( $file );
      @ unlink( $file_time );
      
      return false;
    }

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

Вобщем  недолго думаю крутим туда мемкеш, настраиваем базу, чтобы она легша переваривала индексы, добавляем индедксы везде, все таблицы в иннодб, поле text в product_attribute ставим индекс full_text. И бинго - без кеша мега фильтра на самой большой категории 1.5 сек. А с кешем - 0.5 - 0.7

За неделю!
Три очень крутых кейса. Когда у людей перестала болеть голова.

Три крутых кейса, которые были бы не возможны без отличного физического серверного ресурса!

И три крутых кейса, потому что там были все возможные здешние и не здешние оптимизаторы, какие-то специалисты с именем, какие-то суперхайлоад фирмы, которые нигде никто не смог!

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

Все кто могут сделать отличные решения на opencart под любые условия - все таки живут на форуме. И это круто, и я очень благодарен тому, что в моем окружении есть несколько достойных специалистов в своей теме...

Ну и еще такой небольшой бонус. Как не надо делать...

Пишет тут в чатик @ocdev_pro, мол так и так, у него большой клинент, полдня лежал потому что место закончилось.

Магазин на 5000 товаров на впсе на 100 гиг места. Место мазафака закончилось. СЕРЬЕЗНО!

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

сто гиг йок!
Ок.. Смотрим по тим вьюверу. Доступов же нету! И блин ну вот сразу! 
Этот суер админ настроил локальные бекапы.
Просто он взял и выжрал все место на сервере! Ну круто же!
Чувак пару соток в меся получает за то что взял и обгадил своему работодателю бизнес на два дня..

Перенастраиваем все на хетценр стораж, делаем бекапы. И вуаля!!!
Места у нас 80 гиг, сайт не ляжет. Бекапы удаленные, и еще снепшоты полного соятония сервера настроили.
Владелец магазина немного ошарашен за такого администратора.

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

Знаете если даже ваш микрокиоск, приносит 500 долларов в месяц. Даже если 200. Это 2400 в год. А бекап вам будет стоить 4*12 = 48, просто фактически за 50 евро, вы получаете гарантию, что ваши дети не пойдут по миру.

Доклад окончил, всем спасибо, дали буде.
Ваш Вождь Йоба!

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

3354 / 21729 * 100 = 15.4

3354 / 21729*100 = 11

2137 / 17598 *100 = 12.1

2342 / 18995 *100 = 12.4

1605 / 8593 *100 = 18.7

991/ 5686 *100 = 17.4

969/ 4408 *100 = 22

168/ 628 *100 = 27

1107 / 2508 *100 = 44.1

Думаю дальше продолжать не стоит!
Вот вам и вождь, вот вам и секта.
Думаю никто не посмеет @spectre упрекнуть в аффилированости со мной!

Выводы, как всегда делайте сами!

Кароче мне, один мой товарищ прислал два скрина, как оно бывает...

Подоплека нашей с ним тесной дружбы была следующая, у него стояли какие то там лайтнинги, джет кеши, хрен пойми еще что, магазин не работал, падал в выдаче яндекса, а в гугле не было трафика совсем. В июне-июле мы сделали полнейший подход по настройке-оптимизации проекта, пришлось привлечь чуть ли  не всю нашу банду, для закрытия вопросов с фильтром, версткой, и сделать огромное количество тонких настроек магазина, дабы он стал удобный и понятный для покупателя. Тогда помнится мы сразу получили вот такой результат:

Это замечательно, фантастически - и мы вернули за три месяца трафик по яндексу и он даже начал расти, сугубо настройкой сервера и магазина...
Однако, как вы видите у нас есть аномалия с гуглом. Если кто внимательно следит за гугл вебмастером, у них месяца четыре ничего не работало, нельзя было страницу в индекс добавить принудительно, и отчет о обходе страниц был с лагом в несколько недель.

Так вот. Так совпало, что когда гугл починил вебмастер, вот те самые два скрина:

Мысль одна:

За это время с магазином глобального ничего не делалось, не проводилось больше никаких работ. Ничего. И тут вдруг такая фантастика.

К чему это я все написал спросите вы? Йода, ты опять устроил черный пиар кривых своих доработок? Ты мстишь дырявому бракибраку?

Думайте друзья что хотите, за что купил - за то продал. Единственное, что в отличии от всех остальных докладчиков, в нашей лабораторной работе мы можем наблюдать реально влияние скорости загрузки сайта на позиции в выдаче - а не гадать на кофейной гуще. Как другие докладчики типа:

Ну и все это было бы не совсем полным описанием истории. Если бы я не привел еще один магический график:

Если кто не знает где его взять - найдите его в в настройках в гугл вебмастере в разделе статистика сканирования. Вот как по мне - этот показатель наиболее ответственен за качество сканирования вашего магазина.

Ответ у меня для него было простой: ставь, то что тебе более привычно. Так как это просто в конечном итоге сэкономить время и уменьшит головные боли.

В свою очередь я на стороне центос вот по каким причинам. centos - это все таки почти RedHat, а это типа enterprise. Понятное дело, что львиная доля понятия enterprise сводиться к качественной быстрой поддержке и экосистеме из специалистов, которые существуют в природе в достаточном количестве с быстрой доступностью, но так или иначе, без качественной оттестированной кодовой базы, сделать хороший сервис не выйдет.
А так же есть определенный набор инструментов, которые приходиться повседневно использовать, и которые в centos есть в базовых репозиториях, а вот под debian их приходится собирать из пакетов, дружить зависимости и вот это вот все.

А какие у вас на этот счет мнения?   

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

А вот все остальное поливаешь грязью. И так далее.

Мол кто-то где-то мздит.

Давайте расставим все точки над i. 
Турбо разрабатывался в формате решения вопросов с дефолтным опенкарт и на момент его создания решал очень много вопросов. Сегодня, с появлением быстрых хостингов, с тем, что разрабы стали меньше тупить, возможно делать на холодную быстрые магазины, которые в целом не намного медленнее работают без каких-бы то не было глобальных кешей html-контента.

Вот например ответ сервера у хорошего магаза, у которого все страницы работают быстрее чем 99% покупателей джект кеша.

Чем меньше у нас кешей -тем более актуальные данные. Чем более актуальные данные - тем лучше мы торгуем.

Но... есть два момента, давайте разберем каждый отдельно

Требования google pagespeed.

Уже с год, гугл поменял алгоритм оценки качества страниц, и вес оценки времени генерации страниц несколько нивелировался, и начали учитываться такие факторы, как-то количество внешних скриптов, размер контента на странице, количество элементов DOM и вот это все что вы видите в результатах оценки на странице pageSpeedInsights.

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

Ну и да.. Показывают клиенту богатую зеленую пузомерку в pagespeed, а то  что весь контент развален, аналитикс и метрика работают как попало, пользовательские метрики через одно место. Их не волнует - главное что вы им заплатили за их уникальные поделки,  и вам показали красивую картинку.

С таким же успехом, можно каждому сделать вот так, как у господина @spectre и начать лечить геморрой огурцом! 

https://developers.google.com/speed/pagespeed/insights/?hl=ru&url=https%3A%2F%2Ffreelancer.od.ua%2F

А еще специалисты делают инлайн скриптов-стилей в тело HTML, я своими глазами видел 5Мегбайт код HTML на странице! 5 Мегайбайт КЭП!

А еще, рассказывают с пеной у рта, что изображения webp  ничего не дают. Ну да ну да. Экономия в 30-40% на статике - ничего не дает!
А еще вставляют пауков, которые обходят в фоне страницы сайта генерируют кеш(ага ага, на какие нить 20 000 страниц, сутки ходим), все уже десять раз протухло.
Воруют друг у друга решения (типа как маркукша у ситикриатора webp компрессор). 

И бесконечно несут какую-то дичь. Лишь бы с очередной жертвы маркетинга купить себе бутлочку коньяка.

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

Так что к сожалению или к счастью для избранных, автоматизация повышения качества страниц для оценки GooglePageSpeed - это миф из Нью Васюков.

А вот второй процесс, от которого есть действительно толк называется:

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

Представьте себе, у вас 20-30 к посетителей в день. В пик к веб-серверу приходит несколько десятков запросов в секунду на генерацию динамического контента.
И у вас может быть мега быстрый сайт, но для того чтобы такое держать стабильно - необходим запас мощности и быстрый сервер и это дорого. 
Представьте, что у вас основной трафик идет на 10-15 страниц от всего сайта. И вот для того чтобы не тратить лишние деньги на серванты, мы совершенно спокойно, можем приземлить весь активнй трафик на готовые закешированные HTML страницы и надолго отсрочить миграцию на более жирные ресурсы. И вот в таком случае. Нормальный html full кеш мастхев.
И только в таком случае!!! Во всех остальных стоит озаботиться сперва быстрой генерацией на холодную! Потому что краулинговый бюджет, быстродействие для залогиненных пользователей и вот это вот все!

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

Так что господа, пользуйте нормальные хостинги, не покупайте кривые хламушники 9999 в 1, и да пребудет с вами трафик и бабло! 

p.s. И да.. Господа писатели кешеров.
Если вы захотите тут похоливарить, и рассказать что я в очередной раз несу бред.
Я готов обсудить...

Если вы мне покажите хоть кто-то, подобную динамику роста трафика от ваших решений: