Opencart 3.0 релиз

opencart3

Сегодня Денил Керр, выпустил opencart 3.0

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

Ждите.

Хуйнаныр(10)Очко(2)

Заметки на бегу

Чуваки, ну я тут в полном цейтноте. Так что не очень получается развернуто и постоянно писать.
Но есть пару новостей, которые я не могу обойти стороной.

1. Мы запустили совместно с Диноксом биржу фриланса на Тамаранге
Fl.opencart.pro.
Пока в тестовом режиме, сами пытаемся понять как это работает.

barabara

2. Каталина сделала БЕСПЛАТНУЮ ВЕРСИЮ шаблона Barbara.
Шаблон ФРИ — то есть даром. Без срока ознакомительного действия.
Единственное в нем нет встроенных модулей, которые есть в платной версии.

3. На выходе свежий апдейт сборки pro.

to be continued….

Хуйнаныр(8)Очко(0)

Прямой эфир.

8:17 Динокс, ты проснулся?

8:18 Ненавижу утро. Стадо дятлов в моей голове

9:48 на месте

10:14 ненавижу хипстеров

11:47 продам блокнотик 35грн. 30 грн от пяти штук.

12:48 приходил nice.chat. Nice!

17:48 ничего не происходило. Но вдруг на нас напала Тамаранга.

Аля улю. Постный эфир получился. И ифорум тоже постный.

Хуйнаныр(12)Очко(4)

Barbarar не Стрейзанд — а шаблон для Opencart от Katalina (реклама, пост не проплачен)

prev36001

Рады вам презентовать новый, современный, продающий, кроссбраузерный, адаптивный шаблон «Barbara» для openCart\ ocStore v2.1.x — 2.3.x / 2.1.x — 2.2.x — 2.3.x.

«Barbara» обладает широким спектром дополнительных возможностей, позволяющих:
— изменять внешний вид шаблона (шрифты, цвета, расположение блоков и элементов)
— подключить модули повышения продаж и лояльности к покупателю (быстрый заказ, предпросмотр товаров, мега-меню, новости с категориями и т.п.)
— выбрать одну из 4 тем шаблона, которая будет наиболее подходящим фундаментом для воплощения ваших дизайнерских идей.

Демо-сайты:
http://demo1.opencart4you.ru
http://demo2.opencart4you.ru
http://demo3.opencart4you.ru
http://demo4.opencart4you.ru

Купить можно здесь и здесь.

 

p.s. (а еще, Катя обещала сделать полную адаптацию под Pro).

Хуйнаныр(6)Очко(1)

Быстрые магазины, кеши, php7, и что все это значит (обновлено)

rabbit

Те кто меня постоянно читают, знают что я сделал целую серию постов «тормозит opencart», они вышли достаточно сумбурными и понятны зачастую, только специалистам.
На волне этих постов и повсеместного засилия сеошников с требованиями получить зелененькую пузомерку PageSpeed или любителей подраконить в Gmetrix, появилась куча «ятожемогуев» которые начали всеми силами оптимизировать и переоптимизировать магазины.

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

Очень давно у меня зрел пост именно для владельцев магазинов. Я попытаюсь понятным языком объяснить, что такое кеши, чем они отличаются друг от друга, почему calc_found_rows — плохо, почему индексы в mysql — не панацея, и почему сервер как у пентагона не дает явного прироста производительности. Погнали…

Что такое кеш, какие они бывают и почему он может быть не только полезен но и вреден?

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

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

Так как в магазине у нас очень много однотипных данных и блоков — то подобный подход позволяет существенно экономить ресурсы.

Практика кеширования используется повсеместно. Но кеш кешу рознь.
Давайте разберемся какие бывают кеши.

Есть системный кеш движка, есть кеш изображений в движке, есть кеш запросов mysql, есть глобальный кеш html, есть кеширование байт-кода (opcache), а есть еще кеширование статических ресурсов типа картинок, скриптов и стилей css браузерами.  А еще есть страшные слова типа memcache и varnish.
И весь этот огород если его правильно настроить играет как симфонический оркестр большого театра. Но ни один оркестр не умеет играть без режиссера.
А теперь давайте по пунктам. Что это за кеши и зачем они нам нужны.

 Системный кеш.

В Opencart, его разработчики, встроили механизм, который позволяет запоминать и использовать вновь любые данные. Например вместо того чтобы делать 3-4 запроса в базу данных, для того чтобы получить список языков или валют магазина, эти запросы делаются один раз, потом сохраняются в специальный файл, и в следующий раз при генерации страницы, не происходит обращения к базе данных а выполняется очень быстрая операция чтения готовых данных из файла. Но разработчики системы используют этот механизм в ограниченном количестве ситуаций, хотя само собой просится повсеместное использование.
Например, представим, что у нас в магазине 100 категорий, чтобы получить структуру меню, нам надо сделать 100 запросов в базу (сейчас набегут умники скажут что меньше, но я просто привожу пример для обывателя). И представим, что каждый запрос в базу у нас занимает одну тысячную секунды. Вы скажете это быстро. Но 100 запросов в миллисекунду — это одна десятая секунды. И каждый раз при загрузке любой страницы одна десятая секунда тратится в холостую. У вас 10 000 просмотров страниц в день. 1000 секунд ушло на холостой просчет. А если бы мы один раз сложили меню в кеш — то тратили бы десятую миллисекунды на чтение файла с готовой структурой меню. Сколько деревьев было бы спасено, сколько ресурсов лишних вы оплатили? Понимаете?
По хорошему в магазине все повторяющиеся элементы должны быть закешированы таким образом. чтобы при генерации новых страниц отсутствовало обращение к базе данных. Почему разработчики Opencart не реализовали это из коробки — неизвестно. Но мы реализовали этов нашем модуле Turbo, для 1.5 и для 2.1 и встроили этот механизм в сборку Opencat Pro с версии 2.3.

Кеш изображений.

В магазине мы используем изображения разного размера, в каталогах превьюшки на странице товара большие картинки, а оригиналы у нас могут быть любые. Opencart перестраивает картинки и сохраняет их уже в готовом размере. Т.е. один раз оно перестроилось и следующий раз берется готовое. Так как процесс изменения размеров изображений достаточно ресурсоемкий, вычислительные мощности экономятся колоссально.  Часто бывают ситуации, обращаются люди с текстом: удалил кеш картинок и у меня магазин тупит, или же удалил кеш картинок и поисковик нашел кучу страниц 404. Запомните без надобности не удаляйте кеш картинок никогда. Если вы заменили изображения, его превьюшки сами перестроятся, не нагружайте лишний раз сервер без надобности. А 404 появляется потому что, кеш изображений создается только при генерации страницы, на которой есть изображение. если вы удалили кеш, и не сделали переобход страниц, то поисковый бот делая переобход контента вашего сайта, вместо изображений будет валить на 404 страницу. А если у вас проиндексировано пару десятков тысяч картинок, и вдруг их не стало, вы себе устроите автоддос от поисковых систем. Так как вместо статического файла, бот будет долбится на динамическую 404 страницу.

Глобальный кеш.

Так как вы теперь понимаете, что такое кеш в принципе — вы спросите, а почему бы нам не сохранить полностью всю страницу в файл и при следующем обращении, отдать ее уже готовую и это займет мгновение, вместо долгих и нудных запросов в базу данных, инициализации классов, и вычислений PHP. Ок. Бинго — это отличный подход.
Но он страдает несколькими проблемами. Во первых, у нас постоянно меняются цены-наличие, и время жизни подобного кеша должно быть сильно ограниченно. Во вторых прирост производительности мы получаем лишь в том случае, когда у нас уже есть сформированный кеш. А если у нас  в магазине 10 000 страниц и кеш сбрасывается раз в час, то моментально сформировать новый — на 10 000 страниц — это безумно дорого по ресурсам. В третьих. У нас есть динамические элементы, товары в корзине, отличающийся контент для залогиненных пользователей, товары в сравнении в списке желаний. Т.е. для простого посетителя мы можем отдавать одинаковый контент без проблем, но для залогиненного мы должны делать индвидуальную динамическую страницу с текстом «привет увасся».

Данный подход должен иметь место исключительно в комбинации с предыдущей техникой кеширования однотипных блоков. И он категорически спасает как от наплыва посетителей, так и от проделок конкурентов, которые захотят вас поДДОСИть. Так к примеру самый быстрый-пребыстрый магазин, который у меня получалось сделать, генерит динамическую главную страницу за  80 миллисекунд, в среднем же страница категории с фильтрами, выходит от 200 до 800, а когда у нас есть глобальный кеш, генерация страницы моментальная — это 10-20-30 миллисекунд в зависимости от мощности хостинга, сам контент грузится от сервера в бразуер зачастую медленнее.
Вот поэтому лайтнинг и буст и pagecache — полное дерьмо, потому что они дают прирост только на страницах с готовым контентом, и для каждой новой страницы нам надо сформировать кеш и тоггда быстро. А Turbo для 2.3 и  в сборке Opencart.pro работает на двух слоях: на системном, кешируя однотипные блоки для всех новых страниц и глобальном, кешируя полностью готовые страницы, для всех пользователей и отключая кеширование для залогиненных.

Кеш mysql

Очень часто, когда мне в руки попадает «гавнооптимизированный магазин», который вот работал быстро а щас вдруг лег, я встречаю кешированные запросы Mysql, т.е. все запроыс которые делает движок в базу, какой то идиот придумал потом укладывать в файлы, типа это разгрузит систему. Но это бред по двум причинам. Во первых настроенный mysql (про это ниже) сам отлично кеширует запросы, во вторых скорее всего мы получим ситуацию «плохой кеш», про что я опять же напишу ниже подробнее.

Opcache и кеширование байт кода

Этот процесс не имеет ничего общего к кешированию данных магазина. А делает несколько иное. Как мы знаем PHP — это интерпретатор. А это сразу — медленно. Поэтому чтобы как то исправить ситуацию, разработчики PHP придумали дополнение, которое кеширует байт код и несколько ускоряет выполнение скриптов. Подробнее про это — можете почитать в статье на хабре. Да это дает некий прирост в производительности. Но в рамках 50-100 миллисекунд и доступно это дополнение для php или на нормальных хостингах или на VPS. Кстати у АдминВПС на виртуальном хостинге Opcache включен по умолчанию. Вобщем Opcache полезен — но танцевать с ним стоит в случае, если вы привели все остальное в порядок.

Кеш браузера.

Не имеет никакого отношения к скорости работы движка. Но очень полезная техника. В чем суть. Предположим у вас логотип весит 100 килобайт. Каждый клиент просматривает 20 страниц вашего магазина. И при каждом просмотре на каждой странице вы грузите логотип. Чтобы оптимизировать этот процесс, разработчики бразуеров придумали технологию кеширования статического контента (картинки, скрпиты, стили). Если у вас правильным образом настроена отдача статики, браузеру достаточно один раз загрузить изображение и сохранить его в кеш на компьютер или теелфон или планшет клиента(покупателя), а потом когда он повторно натыкается на этот адрес, браузер не  будет грузить изображение с сервера, а будет моментально погружать его локально с диска компьютера. А если у нас однотипных картинок и стилей на станице на 1.5-2 мегабайта при просмотре 20 страниц наш посетитель сэкономил 30 мегабайт. На быстром интернете — вроде мелочи, а вот для мобильного, медленного или дорогого интернета — это уже существенная экономия. Не зря GooglePageSpeed требует правильно настраивать отдачу статики и дает за это много баллов. Про GooglePageSpeed подробнее ниже.

Почему кеширование не всегда хорошо.
Приведу три примера, когда кеширование вредно, а не полезно.

1) Возьмем к примеру seopro. Когда то freelancer встроил в него кеш, суть механизма достаточно проста. Вместо того чтобы каждый раз делать запрос в базу и искать соответствие роута урлу и урлу роута, Руслан сделал один запрос в базу, который забирал всю таблицу с урлами, потом разбирал эту таблицу  в массив с симметричными связями роут => урл, урл => роут, потом укладывал этот массив в кеш, и в следующий раз система для формирования красивых ссылок обращалась не в базу, а в готовый массив из кеша.
Чудесная реализация, которая на неоптимизированной баз, особенно в версиях 1.5.x на небольших магазинах давала до 500-700 миллисекунд прироста производительности.
А теперь представим, что у нас 100 000 товаров. Мы сформировали наш симметричный массив, и получили 200 000 элементов. Потом сохранили это в файл, мегабайт на 25-30 размером. И потом мы берем этот файл читаем при каждой генерации страницы. Во первых, тратится время на чтение большого файла. Во вторых в механизме кеширования Opencart используется сериализация, и разбор из файла 200 000 элементов в объект — это тоже процесс не быстрый. И вся польза от кеширования не то что сводится на нет, а наоборот приводит к тому, что магазин начинает ползать. И если на 100 000 этот процесс незаметен, то на 200 000+ у вас вдруг появляется лишние полторы две секунды при каждой загрузке страницы, и ни один профайлер запросов вам не покажет откуда они взялись, потому что запросы все быстрые. Поэтому для больших магазинов подобный кеш использовать невозможно.

2) Возьмем модуль ocfilter — вроде бы его автор исправил все запросы, оптимизировал все что можно. Но… на магазине в 30-40 000 товаров, этот модуль формирует дикое количество предварительно подготовленных данных вроде бы для оптимизации процесса, но загрузка и разбор данных из сохранненных файлов в объекты php опять же происходит к плачевным результатам в плане производительности, я встречал магазины на 20 000 товаров которых стоял ocfilter, но в связи с большим количество атрибутов-опций, при каждой генерации страницы туда-сюда гонялось 60 мегабайт данных.

3) Есть еще ахренеть идиоты, которые умудряются закешировать данные метода getProduct. Простым языком в движке есть кусок кода, который выдергивает из базы данные о товаре и отдает уже их в сводном виде.  Предположим, что у нас 100 000 товаров и боты с посетителями нагнали за полчаса 30 000 файлов такого кеша. У нас магазин что? Правильно лег! А почему: а потому что мы уткнулись в специфику работы linux с файловой системой. Из-за большого количества файлов в одной папке, доступ к этим файлам занимает ощутимое время, и вместо прироста производительности мы получаем магазин труп. У вас может быть мега-быстрый диск, но файловая система — это файловая система.

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

Memcache Varnish и остальная шняга.
Достаточно часто от разных горе-специалистов мы слышим — ой, поставили memcache и все залетало. Такая ситуация актуальна была в двух случаях, да и то не залетало, а стало чуть быстрее работать.
Первый случай это большие магазины на 1.5.x, второй случай это медленные старые sata — диски на хостинге. Memcache  — это key=>value хранилище, которое позволяет сохранять кешированные данные не на диске а в памяти. Да это очень быстрый механизм, да он дает некий прирост. Но с появлением ssd дисков и с устранением проблем в механизме системного кеширования в ветке 2.x, использование memcache вы или не заметите, или он будет на общем фоне бутылочных горлышек не заметен. Вот здесь ветка обсуждения темы на Динокс-форуме. Опять же из своей практики, несколько раз внедрение memcache дало прирост в 50-100 мс, но на очень больших проектах с большим трафиком. И вэтих случаях использование этого мезанизма имело смысл, так как мы боролись за каждую милисекунду. На магазине до 20 000 товаров, смысла 0.

С кешами я думаю разобрались. Теперь давайте перейдем к Mysql.

Но сначала сделаем небольшое отступление. Хотя мне надо было написать про это в начале статьи.
Интернет-магазин, как и любой интернет-проект, это фабрика. Если приводить понятные аналогии — то магазин очень похож на автомобильный конвейер. У нас есть чертежи(структура магазина), у нас есть дизайн, у нас есть склад запчастей (база данных), сборочный цех (программа написанная на php) и отдел продаж-управления-упаковки-выдачи(веб сервер).  И если у нас будут плохие чертежи — будет жопа, если маленький цех, будет жопа, если картавый продавец, будет жопа, если дырявая упаковка — будет жопа. На хорошем заводе все элементы производства должны работать как часы, нельзя просто так взять и взять, необходимо устранять все проблемы и оптимизировать все этапы.

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

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

И если с движком все достаточно просто, основной принцип — все элементы должны делать как можно меньше однотипных вычислений и использовать как можно больше наборов одинаковых данных, то настройка сервера mysql, индексы базы данных и запросы в базу — это целое искусство. И оптимизацию любого проекта необходимо начинать именно с базы. Так как 80% времени генерации страниц магазина занимают именно запросы в базу. Вот про это про все сейчас попробую подробно.

Ситуация первая — я взял выделенный сервер, у меня террабайт оперативной памяти, intel core 777. А магазин работать быстрее не стал. 
Такое бывает часто густо. А все почему. Потому что когда вам поставили linux на сервер, в 99% его поставили с параметрами по умолчанию. У линукса основной принцип — это стабильность. Соответственно когда ставиться по умолчанию mysql сервер, ему вместо ваших скажем 16 гигабайт памяти, для работы доступно 16 мегабайт, а вся остальная память лежит мертвым грузом. И при выполнении каких либо тяжелых запросов система обращается для хранения промежуточных данных на диск. А когда мы обратились к диску — все… вся мощ процессора, все ваши миллионы гигабайт оперативы все коту под хвост. Так это устроено. Пока вы не разрешите Mysql использовать вашу память по полной программе, она даже знать не будет что ее дохрена, и будет за неименеем горнишной ебать дворнка во все дыры. Это я привел очень очень грубый пример. Все на самом деле сложнее и в Mysql есть порядка 20 обязательных параметров, которые необходимо настроить для того чтобы она по полной использовала ресурсы вашего жирного железа. В ином случае ваш сервер как у пентагона будет не шибко быстрее чем дешман-шаред-хостинг. Мало того нет универсального рецепта или конфига для mysql сервера, который бы позволил решить все эти вопросы одним махом, так как все индивидуально зависит от параметров сервера. Если кому хочется углубиться в тему — читаем подробнее на хабре.

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

Во вторых давайте попробуем разобраться что такое индексы, и почему нет универсального рецепта. Данные в базе хранятся в виде таблиц. Вот оочень похожие на таблицы экселя. Когда мы делаем какой то запрос. в 99% случаев мы ищем данные по какому то совпадению цвет «красный» например. Как делает поиск система. Она берет, открывает файл в который записана таблица, перебирает его и ищет совпадения с нашим параметром, и выводит все результаты, которые нашла. Ну представьте таблицу на 100 000 записей, в которой 5 раз встречается слово красный. Наш бедный процессор, надрывается, усирается, но как покорный раб, каждый раз при каждом запросе все равно берет и перебирает весь файл. Что же делать? А делать тут все просто. Мы можем заранее найти все вхождения, и сделать для них такой себе словарик. И мы уже будем знать что слово красный встречается 20 раз и находится в ячейке 20 400 и 534534 ну опять же к примеру. И если у нас есть такой словарик, вместо поиска по всему файлу, при запросе система сделает поиск по нашему словарику, тому самом индексу, и в один присест очень быстро вернет нам результат. Это в тысячи и тысячи раз быстрее. Подробнее как это работает — читаем на рухайлоад.
Казалось бы все так просто — и это решает все наши проблемы. Но все да не все.
С одной стороны индексы существенно упрощают выборку и сортировку данных. Но с другой стороны они тоже занимают место и не везде применимы. Так например если взять поле значений атрибутов, то у него тип text, а на поля типа text, мы не можем применять индексы — мы можем использовать full-text индекс, но они дают эффект только при поиске, и не работает при обьединении таблиц а также актуальны для значений более четырех символов.
Что то я загнался по моему опять.
Давайте чуть сначала. Данные у нас хранятся в куче таблиц. Чтобы получить например результат фильтра, движок может обращаться к паре десятков таблиц, объединяя и сортируя данные одним запросом и перебирая сотни тысяч строк. Если мы правильно расставили то при каждом объединении таблиц у нас не перебирается вся таблица, а используется ограниченный набор данных. Например если мы работаем с товарами из определенной категории, то мы сужаем набор обрабатываемых данных до товаров именно из этой категории. Но это при условии что у нас правильно созданы индексы и правильно построен запрос. Так как 99% пейсателей модулей слабо понимают чем отличается STRAIGHT_JOIN от LEFT JOIN и не знают что такое оптимизатор mysql, то говорить о каком-либо оптимзированном коде запросов дополнений не приходится от слова совсем и работать приходится с тем что есть. И зачастую из-за конфигурации сервера и настрйоки системы одни индексы которые работали на другой базе как молния на второй начинают тупить. Потому что есть такое понятие как план запросов и есть оптимизатор mysql, который сам себе решает где и на каких выборках, какие индексы использовать и использовать ли их вобще, и тогда начинаются танцы с бубнами, сложные составные индексы и бесконеные построения перестроения и эксперименты. в 99% случаев получается обходится без переписывания запросов но не всегда.
Вы спросите — если все так сложно, как же работают системы не на 100 000 а на 10 000 000 товаров. Я вам расскажу. Во первых в подобных системах все данные денормализуются(сводятся) в плоские таблицы, для того чтобы исключить процессы объединения-выборки из нескольких таблиц, во вторых везде повсеместно используются key=>value хранилища типа memcache или sphinx, в третьих nosql хранилища типа MongoDB  — но это все уже BigData, а мы говорим про небольшие-средние интернет-магазины и оптимизацию малой кровью. Поэтому индексы это хорошо и полезно, но они не панацея, нет универсальной таблетки, и не во всех реализациях они применимы — так например быстрый релевантный поиск на php это то еще изобретение велосипеда, а к примеру при сортировке по LCASE(name) индекс нам не поможет, потому что вычисления сортировка идет по временным данным — преобразованному названию  в нижний регистр, а не по индексу. Оба процесса кстати решаемы даже в наших реалиях. Для поиска достаточно использовать sphinx а для быстрой сортировке по названию мы можем сделать дополнительное поле с заранее подготовленными данными, но это опять же изменение  структуры таблиц, и не всегда игра стоит свеч. Но на каждую хитрую гайку найдется хитрый болт, и практически все задачи связанные с хранением и быстрой выборкой данных решаются при помощи тех или иных техник, все упирается в ресурсы и потребности заказчиков.

Вобщем с базой мы вроде бы разобрались. Нормально настроенный mysql-сервер и правильно расставленные индексы — это 50% успеха. Едем дальше.

У нас есть индексы, у нас есть  кеши, у нас правильно настроенный mysql-сервер но все равно сервер ложится от нагрузки и нагрузка на базу. что делать? Бывает и такое.

Чтобы вы понимали… Mysql работает по принципу когда пишу не читаю, когда читаю не пишу, сделано это для того, чтобы сохранялись зависимости между данными и не наступил коллапс и неразбериха. Это так называемая персистентность. Так вот, бывает когда вам написали кривой парсер, который в фоне хуярит нон-стоп во все таблицы и просто их запирает. У нас быстрая база, но парсер настолько тупой, что нагрузил все и наш мегасервер свободен, но база лежит. А лежит потому что таблицы заперты записью. Поэтому парсеры должны работать ночью. Или порционно. Так и передайте их писателям.
Еще чаще бывает. Что все ресурсы базы забирает на себя поиск. Есть такой известный гандон sv2109, который написал типа поиск с релевантностью и морфологией. Ок ок.. спиздил где то алгоритм. Который дробит поисковую фразу на куски потом еще на куски и еще и шлет в базу ахулиард тяжелых запросов для поиска всех возможных вхождений из поисковой фразы, а потом еще и перебирает-сортирует выбранные значения. Помните я загадывал загадку, почему у клиентов тупил магазин. Так вот это был именно поиск от sv2109, на 10 000 товаров, любой запрос в поиск занимал 2 секунды, и эти 2 секунды этот запрос выгрызал 100% ресурсов серевера mysql — и все.. Магазин лежит, клиенты уходят, боты не индексируют. Будь моя воля, я бы ввел санкции против sv2109 не только на территории Украины, а во всей галактике, потому что более тупого-амбициозного ублюдка сложно придумать. Ну хотя нет. Soforp будет круче. Но это я опять ушел от темы.
Вы скажете мол, у меня нихрена не ищут, откуда у меня запросы в поиск. Кроме запросов, у большинства бывают теги товаров. Теги в Opencart реализованы через жопу — а именно через поиск. По сути любой тег — это поисковая фраза, которая правда ищется только по полю тегов. Но это все равно ооочень плохо. Полнотекстовый поиск и PHP — это как два хуя в жопе, кому то нравитсян

Нормальные люди давно используют для поиска sphinx, да это можно реализовать на выделенном сервере — но и быстрый магазин на дешман-хостинге у вас не получится. В чем смысл сфинкса. Это такой себе механизм, который приходит в вашу базу данных, читает ее.. Формирует глобальный общий словарь всех слов  и словосочетаний из них, которые встречает, создает из них каталог, и потом предоставляет удобнейший механизм поиска по этому словарю по вашей поисковой фразе. Так как сфинкс заточен на поиск и больше он ничего делать не умеет — это идеальное решение. Да настроить сфинкс на сервере и подружить его с opencart — не тривиальное решение, есть бесплатный модуль на офсайте, но сколько раз я его не ставил он у меня ни разу вот так сразу не завелся.
Также не зря модуль бесплатный, для того чтобы получить нормальные результаты выдачи — пришлось попотеть почитать мануал и доработать конфиг и код модуля. Но в итоге получился очень приемлемый, а самое главное очень быстрый поиск.

У меня выделенный сервер. А работает медленнее чем на виртуальном хостинге?
Выделенный сервер — выделенному серверу рознь. Если вы купили какой нить corei3 8gb SAS HDD — не ждите, что он заработает быстрее чем самый дешевый виртуальный хостинг от AdminVPS к примеру.  Потому что у них может стоять Intel Xeon E5-1650v2 Hexa-Core, который в десятки раз мощнее чем ваш Corei3 и операции выборки сортировки данных в базе он делает также в десятки раз быстрее. А вы же помните — основной тупняк у нас база.

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

Да бывает и такое. В большинстве таких случаев проблема бывает не в скорости запросов а в их количестве. Есть пейсатели модулей, которые умудряются при выводе 100 товаров в какие нить таб-модули, создать 1500-2000 запросов, был такой чудный brainy-filter, который создавал для выборки временные таблицы, которые тоже не оптимзируются индексами и это очень плохая техника, был Simon-filter, который мог на одну страницу сделать и 4 и 6 тысяч запросов. Есть авторы модулей, которые пишут запросы вида SELECT * ….. ORDER BY RAND(), и подобная чушь в принципе может затупить любой сервер с любым процессором и любым количеством памяти на таблице в 100 000 товаров.
И каждая ситуация индивидуальна. Невозможно написать кеширующий модуль всего и вся. Чтобы исключить множественные тысячи запросов во всех модулях. Невозможно всем авторам обьяснить что вместо SELECT * ….. ORDER BY RAND() надо делать SELECT product_id … ORDER BY RAND(). Поэтому такие ситуации всегда индвидуальны. Где-то приходится переписать код запроса, где то вручную прикрутить кеш, где-то менять модуль на другой, благо есть тот же нормальный фильтр от ведьмы.

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

Было две истории у меня, реально смешные.

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

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

А еще щас появились блять умники, которые рассказывают про быстрый php7 и по http2.0

Скачал про php7 — да реально он быстрее чем 5.3 и иногда значительно. Но, еще раз повторяю время обработки данных скриптом в магазине — незначительное. 10-15%, Меняя версию PHP, мы получаем всего 3-5% общего прироста производительности, и кучу головной боли связанной с несовместимостью кода и настроек сервера, а также отсутствие Ioncube — который из песни слов не выкидыш. Реальный же выхлоп от php 7, в том что там реально стало много OOП и всяких трейтов замыканий и прочей технологичной лабуды, которую Даниеэль пока не соизволил использовать, так что, попрошу в каментах на эту тему холивар не разводить — если кому охота — идите поговорите с Марком.  Де-Факто толк от использования 7.0 пока что в рамках статистической погрешности.

Почему вам не поможет CDN.
Когда вы сталкиваетесь с тормозами магазина — вы лезете гуглить. Как ускорить сайт. И везде натыкаетесь на общие советы. В которых очень много текста про сжатие статики, объединение-минифкацию скриптов, сжатие картинок и CDN — там нигде не пишут, что ваша основная задача сделать быстрым TTFB (time to first byte) время которое проходит между обращением из браузера на сервер до момента, когда сервер отдает браузеру HTML контент. В век достаточно быстрого интернета, все остальные задачи вторичны. TTFB — наше все. Так вот. Давайте про CDN, что это такое. Если по умному по английски — это CONTENT DELIVERY NETWORK. Если приводить аналогии с заводом — то это региональные склады товарных остатков. Например чтобы торговать в нью-йорке грязными японскими трусами, проще завести контейнер трусов из японии и торговать там со склада, чем слать каждому индивидуально пакуночек через океан.
Существуют специально-обученные сервисы, которые могут сделать то же самое с вашими картинками. Разложить их поближе к вашему покупателю и отдать быстрее контент. Тем самым достигается сразу две цели. Во Владивостоке клиент грузит картинки быстрее с местного cdn-узла, чем с вашего сервера из Москвы, а также разгружается в целом ваш сервер при отдаче контента, так как запросы на отдачу картинок идут не к вам, а к CDN-провайдеру. Красиво звучит, правда ?
Но… это актуально НА БОЛЬШИХ ПРОЕКТАХ, с огромным трафиком, и множеством серверов. Когда у вас у большинства едва ли на 20% загружены ресурсы VPS, какая разгрузка сервера, о чем вы… Да и никто в основном не торгует и на Америку и на РФ, чтобы запариваться насчет скорости доставки картинок вашим клиентам. Это очень хорошая технология, от нее есть много пользы, но применять ее стоит там и тогда когда она актуальна. А когда опять же далеко не у всех решены вопросы общей производительности, CDN — это самое последнее с чем стоит заморачиваться.

Почему в 99% случаев нет разницы между NGINX и APACHE.

Опять же возвращаясь к высокопарным пидарастам с Opencartфорума, которые думают, что они думают. Было несколько дискуссий — как прекрасен и быстр NGINX — не вопрос, он прекрасен. Но… Что Nginx, что Apache — это просто прокладки между вашим браузером и обработчиком PHP, т.е. вы стучитесь из браузера на сервер и говорите — хочу анкету голой бабой по имени люся.  Apache или NGINX чешут репу и смотрят, ага, есть у меня сайт проституток на который ща постучали, его скрипты там то и там то, задам вопрос обработчику PHP- есть ли у него анкета бабы люси. Обработчик php лезет в базу ищет бабу люсю и передает в нежные руки Web-сервера ее данные фоточки и остальную шнягу, а веб-сервер передает ее вам.

Так вот… процесс обработки запроса из мира, передачи в php и отдачи даннных наружу у этих серверов по скорости НЕ ОТЛИЧАЕТСЯ!  Точнее отличается в десятитысячные секунды. Да NGINX гибче и мощнее, да он нативно умеет делать мультипоточную обработку запросов без всяких PREFORK и ITK модулей. Но, почему-то 99% хостинг провайдеров ставят связку NGINX => APACHE => Обработчик PHP. Не задумывались почему? Да потому что Apache — де факто стандарт. 80% серверов в мире работают на нем. Большинство пользователей элементарный редирект в htaccess сделать не может. Какой к черту чистый NGINX. ЗАЧЕМ???? Получить + 5-10 мс прироста скорости, ради того чтобы какому-нибудь еблану заплатить сотнягу зелени за настройку конфига и потом на него не дышать?
Кароче, в 99% случаев заводить Opencart на чистом NGINX — это так же как глушить рыбу динамитом.
Да это круто, и когда мы делали площадку для Opencartфорума мы там и PHP 7 запустили и чистый NGINX вкрутили и много еще чего сделали, но господа, там у нас 1 500 000 просмотров страниц в день. А для магазина даже в 10 000 хостов в день. ЗАЧЕМ ?????

Плчему louise-какие то цифры тупая пизда, и почему нельзя напрямую пользоваться сторонними API. И что делать если сильно хочется.

Про луис — отдельная песня. Это упертой быкобаран, которая онажемать и типапрограммист, который красит губы буржуйским модулям и выдает их за свои.
Кроме этого она ахуеть хамит клиентам, не признает свои косяки, но очень оперативно подчищает следы. Так например, одному моему товарищу ее почта-россии срезала порядка 120-150 заказов. У нее видите ли лег сервер авторизации модулей, и когда модуль пытался проверится на легальность а унего не получилось — он самоудалился,  в итоге оформление заказов не работало на хуй совсем. Ну  я считаю что заебись модуль. который нарисовал минус 6-8 тысяч долларов оборота.

Кроме этого у нее модуль мультивалюты, который при определенной конфигурации стучался при каждой загрузке на сервер центробанка, проверял курс и подставлял уже обновленный реал-тайм курс в магазин.
Вот какая блять может быть оптимизация, сидишь куришь запросы, код все забеись. А 500 миллисекунд лишних откуда то лезут. Полсекунды на каждой загрузке магазина — и так каждый раз. Оказалось что это просто время, которое тратится на обращение на сайт ЦБ РФ. Ну не ахуеть ли. Ну надо тебе реал тайм — ну возьми ты закешируй на часик эти данные. Это первый момент.

Второй момент. Если идет подобное обращение на какой то сайт или на чужое API, и ресурс недоступен. У нас ложится магазин. Просто ложится на хуй. Такое было недавно со всеми, у кого стоял модуль инстаграмма. Инстаграм лежал, и сайты лежали. Ахуеть же программисты делают. Мало того что это все тупит на хуй магазины, так еще и  при любом падении все ложится.

Что делать спросите вы.. А делать тут можно все очень просто. Любые обработчики, работающие c внешними API должны работать паралельно основному скрипту и реализовываться через AJAX. Ну кто мешает сделать тот же модуль инсты — AJAX модулем? Который не будет никак влиять на работу основной системы. Лег инстаграм. Ок, просто у нас не построился контент в блоке, работает — ну и заебись все.

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

Очень много ботов (ocfilter) и как такое можно было придумать.

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

/ноутбук/lenovo/17/red — точно не помню но суть я думаю ясна. Т.е. под все возможны опции атрибуты варианты категория/производитель у нас уникальная ссылка.

И по легенде хуесеошников, такая практика должна дать ахуеть сколько трафика. Так же у розетки сделано — и посмотрите сколько у них клиентов.

Ок заебись, не поспоришь, но… В розетке — на таких страницах ЕСТЬ КОНТЕНТ!!!! Это не тупо 100500 страниц в индексе. Это 100500 полезных с точки зрения поисковика страниц в индексе. 90% владельцев магазинов не могут просто описать категории. Половина из оставшихся — заказывают гавнотексты на адвего и только вторая оставшаяся половина может самостоятельно сформировать нормальный полезный, удобочитаемый контент.
Собствено 5% то и зарабатывают. Но речь не об этом. Вы блять категории описать не можете, куда вам еще миллион страниц фильтра.
А дальше… приходит поисковик видит … оооо ахуенно тут много вкусного, пойду я проиндексирую. А в итоге видит однообразные тупые пустые страницы вашего магазина, которые отличаются только названием ноутбук леново синий или ноутбук леново красный а еще ноутбу леново красный семнадцать дюймов.  Ну гуглбот — он же не дурак.
Он думает — да вы меня наебать хотите. Я тут потратил кучу ресурсов и времени. Где тто в мире за это время пропало три зеленых дерева. А я мало того что не дурак, я еще и за экологию. Вы тратите блять ресурсы, электричество, забиваете интернет-каналы полной хуйней. Вот вам БАН БЛЯть. Ну бан не бан — а в выдаче он вас точно не повысит.

Но мы же помним 100500 страниц у нас. И их все боты должны просканировать. Категорий к примеру у нас 30 производителей 50 — получили на выходе 1500 страниц, а если какие то опции атрибуты есть, прикиньте, что мы получаем. тысячи и тысячи бесполезных страниц. Которые бот должен обойти.  У вас может быть 20 калек в день живого трафика, но 200 000 запросов на просмотр страниц ботами. И все.. у вас все лежит.

Ок вы скажете ничего страшного crawl-delay меня спасет. Спасти то спасет, но важный основной контент, когда бот просмотрит, лет через 10, а должен смотреть каждый день.

А еще придет ща Soor и скажет — у меня же Noindex есть.. ХА ХА ХА.. Noindex — не мешает ботам грузить и смотреть эти страницы. И нихуя не решает ситуацию.

Что делать опять же спросите вы… Не юзать подобного рода функционал. А если вы хотите красивые посадочные под НЧ запросы. То делайте их все ручками при помощи того же MegaFilterPro от ведьмы. И тогда у вас будет толк от этого процесса.

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

Катя на днях выкатила шаблон, и шаблон неплохой, ну как красивенький по дефолту. Все шаблоны красивенькие. Пока там авторсике картинки стоят и короткие названия товаров. А как начинаются колхоз-фото и 200-300 символво в названии товара — все шаблоны превращаются в гуано.

Но мы ща не об этом.

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

В следующей серии:

В чем смысл инструмента PageSpeedInsight, и надо ли полностью идти на поводу у гугла.

Варезятина и почему это плохо.

Тормоза в примерах:

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

А также почему так много воя от даунов типа dotroxов и компании про то какой дерьмовый Opencart, и почему он должен себе всунуть в рот сто хуйов, прежде чем вякать по этому поводу. И да Opencart — таки дерьмо! Но на свои деньги — это просто бриллиантовый бриллиант.

 

Хуйнаныр(31)Очко(1)

С шоколадным приветом вас, господа

В общем, я надеюсь, что этот пиздец все-таки отыграют в зад.
100500ым КЭПом, который будет рассказывать как все хуево в северокорейских республиках, и как все заебали, быть неохота, вы все и сами все знаете.

Это однозначно пэрэмога.

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

Ну а кто жить не может без любимых пабликов — то пока на декстопах спасает 8.8.8.8.

Хуйнаныр(11)Очко(4)

Заебись!

Пост не про опенкарт.
Но…

110179846

Чуваки и чувихи. Жизнь же он не только из торговли магазинов и всякой негативной хуйни — есть например кено!
Всем кто еще не посмотрел Молодой Папа — категорически советую.

А еще Baby Groot же в кино пошел пошел.

maxresdefault

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

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

Хуйнаныр(23)Очко(0)

Opencart 3 начало

Пока вы все садите картоху, я работаю)

Наконец, появилась возможность посмотреть в Opencart 3, который уже как три недели находится в альфа-версии, поближе.

У Динокса на форуме пиздабольшики развели уже холивар на 7 страниц, как все плохо и какие классные другие фреймворки. Но к ним у меня просто отношение — плохому танцору всегда яйца мешают.

99% пользователям Opencart глубоко похуй на шаблонизаторы, фабрики запросов, и всю остальную техническую муть, на тему которой так любят поволать ебанаты.

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

Во первых Даниэль Керр глубоко срал на подобных холиварщиков и у него свое видение проекта, ебанутое конечно, но с ним ничего не поделаешь.

Во вторых чтобы каким-то образом модифицировать архитектуру и уйти от материнской ветки движка, необходимо большое коммьюнити заинтересованных РАЗРАБОТЧИКОВ, а не пользователей. Поэтому кроме как пиздежом, с учетом кучи умных фраз, подобные темы ничем не заканчиваются и закончится не могут. Пока что нет в рунете достаточно сильного коммьюнити создать и развить нормальный форк.

Ну и в третьих С — СТАБИЛЬНОСТЬ. Стабильность Opencart обусловлена в первую очередь огромным междунардным коммюнити, среди которого есть несколько очень сильных специалистов. Благодаря чему вовремя обнаруживаются и фиксятся хотя бы все security-баги.

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

Что же изменится для рядового владельца магазина?
По моему ровным счетом — ничего.

Шаблоны как базировались на бутстрапе, так на нем и остались (ниже подробнее почему это херово).
Дефолтный шаблон как был с уебищным меню и одним товаров в строке на мобиле — так и остался.
Ебанистически конченное меню в админке с доступом в два лишних клика в модули и шаблоны, появившееся в 2.2 — тоже осталось.
Ocmod — ебучий Ocmod — вместо прекрасного Vqmod  — тоже блять нихуя не изменился.

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

Библиотека seo_url, как была, так и осталась в плане SEO — подвижек никаких.

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

Есть какой то редактор меню, пока я туда не досмотрел.

А в общем и целом, вся эта хуйня пока что ни чем не отличается от 2.3, которая по моему мнению не очень, и становиться 3.0 ей пока очень рано. А приправы в виде TWIG и встроенного магазина дополнений в хуй рядовому пользователю не впились.

А теперь вернемся к вопросу, почему bootstrap — в формате того как его юзает даниэль — дерьмо:
Во первых — уже 4 в альфе и там есть все новомодные flex-штуки. И он намного удобней, но Даниэль наверное про него не слышал.
Во вторых — сам по себе бутстрап очень сильно ограничивает работу с широкими мониторами, ебись со своими 4 колонками и пиздец.
В третьих — он мать его тяжелый. Зачем грузить кучу лишних стилей скриптов, если можно спокойно реализовать базовую адаптивность в 200-300 строк стилей.

Хуйнаныр(28)Очко(4)

Кластеризация запросов. Как продвинуться в ТОП в Яндексе и при чем тут Баден Баден

В продолжение предыдущих постов про баден (первый, второй)  у нас вышел небольшой чат с чуваком, который реально шарит в продвижении в Яшке и моим подопечным, которого победил Баден Баден.

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

[19:46:17] SeoJedi: Как же мне уже заеблось это объяснять )))) Надо походу Йоде запилить статью, чтобы всех туда отсылать )))) щас расскажу
[19:47:03] SeoJedi: короче раньше бытовала легенда что что можно на 1 странице продвинуть ну от силы 5 запросов
[19:47:17] SeoJedi: на самом деле их может на 1 старнице и 500 быть
[19:48:59] SeoJedi: кластеризация делается следующим образом. Берутся запросы из семантического ядра, спец программа делает обращение в ПС и смотрит какая именно страница показывается по этому запросу. Потом она берет эту информация и группирует. например вот по этим 10 запросам показывалась одна и та же страница! Значит эти все 10 запросов можно продвигать на 1 странице
[19:49:22] SeoJedi: это все важно потому что существуют разные типа запросов : коммерческие, информационные и неопределенные
[19:49:36] SeoJedi: у них у каждого РАЗНАЯ стратегия продвижения
[19:50:36] SeoJedi: например запрос «аккумуляторная батарея», вполне может быть ИНФОРМАЦИОННЫМ запросом! А запрос «купить аккумуляторную батарею » точно коммерческий
[19:50:42] SeoJedi: и их нельзя продвигать на 1 странице
[19:51:13] SeoJedi: потому что для инфо запроса нужна простыня 4-15 тыс символов текста, фотки видосы и т.п. (это зависит от конкуренции)
[19:51:26] SeoJedi: а для коммерческого запроса в некоторых нишах текст вообще нахуй не нужен
[19:51:49] SeoJedi: там учитываются так называемые КОММЕРЧЕСКИЕ МАРКЕРЫ
[19:52:09] SeoJedi: чтобы была цена, наличие, кнопка купить / вкорзину / заказать и т.д. и т.п.
[19:52:23] SeoJedi: а на инф запросах такогго вообще быть не должно
[19:53:02] SeoJedi: и короче класлеризация определяет какие запросы можно продвигать вместе, а какие нет и делает это на основание уже существующей выдачи ПС
[19:53:09] SeoJedi: Понятно???
[19:53:39] Жертва Бадена: боль мень
[19:54:15] Жертва Бадена: спец программа платная?
[19:54:51] SeoJedi: да! Софта полно такого, если и сервисы, но не все делают это хорошо
[19:56:44] SeoJedi: и потом текст должен быть релевантет кластеру который продвигается на этой странице + соответствовать по объему
[19:57:14] SeoJedi: например если нужно 2500 текста, то если будет меньше не покажешь и если будет сильно больше тоже показываться по этим запросам не будешь
[19:57:32] SeoJedi: + если еще большая куча других требований к тексту
[19:58:17] Жертва Бадена: мне, как обычному продавану это черезчур сложно
[19:58:36] Жертва Бадена: как заказов не будет — буду разбираться
[19:58:42] Жертва Бадена: будет время
[19:58:44] SeoJedi: да это даже не продавану сложно, но и 95% сеошников
[19:59:09] Жертва Бадена: пока попробую поправить те статьи, которые есть
[19:59:28] Жертва Бадена: поудаляю повторяющиеся слова
[19:59:38] Жертва Бадена: и постараюсь просто сделать для людей

Ну и буду дальше держать вас в курсе этого процесса, надеюсь что Баден Баден мы поборем.

Хуйнаныр(10)Очко(1)

Баден Баден от Яндекса. Что делать?

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

Сейчас он пытается списываться с Платоном. Вот такой вот результат:

Платон отвечает, мол убирайте портянки с сайта
А у тех у кого не портянки — тоже убирайта

тиц убил до 0
вчера убрал статьи со страницы категорий и отправил на пересканировку
посмотрим, как яндекс раздуплится
читаю отзывы в нете — у многих траф. с яндекса упал, даже у тех, кто не под Баденом.. С 900 до 100 человек в день по яндексу от 20 числа… в яндексе нет уведомлений… не знаю даже что делать»

 

baden

 

Пока он в замешательстве. Но посмотрим по результатам пересканирования. Если поможет, я вам детально рассажу что с этим делать.

 

 

Хуйнаныр(3)Очко(0)

Баден Баден от Яндекса

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

baden-baden

 

А теперь давайте подробнее.
Что это такое и с чем это едят.

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

Естественно все  лидеры рынка старались выйти в топ по всем запросам типа «купить», «купить недорого» и так далее. Тупые сеошники, ориентируясь на грандов, всем рекомендовали херачить однотипные метатеги для страниц, которые обязательно должны были содержать словосочетания «КУПИТЬ ВАШУ СКУДНУЮ ХУЙНЮ В ГОРОДЕ УСТЬ-ПИЗДЮЙСК НЕДОРОГО С ДОСТАВКОЙ». И если в описании товара было чуть больше чем три слова, то обязательно те же сеошники рекомендовали сделать акцент на подобные словосочетания в товаре.
Многие ленивые упыри, хуячили автоматическими генераторами метаописаний подобные тексты на все товары и категории магазинов.

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

Но в Яндекс решили ВОТ ВАМ ХУЙ!

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

nakazi

 

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

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

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

За сим пока прощаюсь, извините, что временно пропал. Я вернулся полноформатно.

 

Хуйнаныр(18)Очко(0)

Влияет ли скорость на позиции в выдаче?

rocket

Вот такой диалог у меня состоялся с одним моим товарищем, который похоже и правда немного понимает в seo:
SeoPro: Я тут с Марком спорил )) какое твое мнение — скорость сайта является фактором ранжирования?
Yoda: в гугле да
Yoda: в яндексе косвенно
Yoda: тоже да
Yoda: я тебе обьясню это с другой стороны
SeoPro: Марк говорит что нет. Похуй медленный или быстрый сайт
Yoda: помнишь, мы когда сделали диноксу площадку форум ?
SeoPro: Да помню конечно
Yoda: у него гугл ходил, до переезда на быструю платформу, сканировал до 10 000 страниц в день макcимум, а потом начал по миллиону в день собирать.
Yoda: гугл мониторит
Yoda: какую он создает нагрузку
Yoda: и ее балансирует
Yoda: типа, если ответ сервера
Yoda: замедляется
Yoda: то он выставляет какие то там свои лимиты на количество заходов
Yoda: и повторхных заходов
Yoda: иначе бы он нахуй заддосил весь интернет.
Yoda: Мэт Кац
Yoda: давно сказал что
Yoda: одним из ахулиарда факторов ранжировния скорость уже давно является
Yoda: как бы у них без вопросов
Yoda: т.е. кроме того что влияет на выдачу
Yoda: еще ты успешно отдаешь контент
Yoda: с большей частотой
Yoda: ну поведенческие факторы понятное дело тоже улучшаются
Yoda: потому что меньше отказов
Yoda: т.е. вот тебе три ЗА:
Yoda: 1) лучшая и регулярная индексация
Yoda: 2) официально призанный фактор алгоритма
Yoda: 3) улучшенный поведенческий
Yoda: яндекс — клон гугла
Yoda: убираем
Yoda: 2 фактор
Yoda: остается два
Yoda: более чем достаточно чтобы быть правдой
SeoPro: На пф скорость вообще прямо действует. В Яшке основной фактор ПФ все-таки, т к. Тупые, а до Гоши им еще далеко
Yoda: как не действует
Yoda: если блять
Yoda: людям удобно
Yoda: увеличивается глубина просмотров
Yoda: если есть отслеживание конверсий
Yoda: они тоже увеличиаются, потому что народ не дрочит в монтиро ожидая окончания загрузки
Yoda: а сразу делает необходимые действия

Хуйнаныр(25)Очко(0)

Весеннее обострение | со дна постучали 2.0

ebat

Да уж, накаркал я по самые помидоры про спокойствие в датском королевстве.

Утро началось не с кофе.

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

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

Есть такой чудак exploits — ник уже говорящий (ass exploits) — с английского как раз и будет бомбящий пукан.  И вот этот демон смастерил модуль микроразметки.
Я пару месяцев назад,  задавался этим вопросом — и проанализировал его приблуду, отписав в каментах, что модуль полное дерьмо и категорически не приемлем для использования, так как может легко загасить магазин в бан в гугле.
Порванный пердак на это начал вонять, мол он самый умный и все будет заебись.

И что вы думаете… Еблан сука оказался тугой на всю голову и даже когда ему тыкнули:

perdak

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

Подробности здесь. (ссылка не работает, модуль скрыли).

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

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

 

 

 

Хуйнаныр(33)Очко(2)

Время хорошей музыки

nazgul

Моя старая подруга, которая не певица ротом, а наборот певица с большой буквы, наконец-то прорвалась в топ!
Правда в топ украинской музни.
Но она очень крутая. Кто в Киеве и окрестностях — не поленитесь сходите, будете потом в кайфе на месяц вперед!

Хуйнаныр(5)Очко(1)

Весна идет весне дорогу!

Друзья мои, вы наверное заметили что я сдулся.
И это факт — я сдулся.

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

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

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

Опять душит прокрастинация и очень хочется в теплые края под пальмы.

 

 

 

Хуйнаныр(7)Очко(0)

Оптимизация форума на IPB {Эксперименты и результат}

15822500169_0931f5ecbf_b

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

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

Первым делом было принято решение менять сервер.
Взяли на Hetzner SX61 SSD, настроили ему нормальный конфиг базы данных, нормально настроили связку nginx + apache. Все ожило. Но осталось одно но. Средняя нагрузка на процессор все равно была 60-70% и в пик доходила до 100. А любой паук, собирающий битые ссылки, гугл, или «дружественная организация с DDOSом», могли спокойно обрушить стабильность системы. Так что смена сервера это был первый шаг. Мало  того Динокс на радостях, что форум живой, скормил гуглу сайтмапы, после чего гуглбот заселился по полной на форуме, будто Дэн Билзерян в пентхаусе Беладжио.

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

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

Ну как, не «совсем ничего», разгрузили мы где то процента три. А все почему, потому, что в IPS присутствует несколько недоделанный ORM, который валит очень мало чистых атомарных запросов на чтение. И тут надо вернуться назад, так как нативная репликация средствами mysql возможна только в master-slave режиме, соответственно на слейв запросов уходило очень мало, хотя мы и настроили все в режим master-write/slave-read. Было принято решение разворачивать кластер и делать репликацию по схеме master-master.

Всякие недоделанные оптимизаторы, могут меня ща ткнуть пальцем в статью на ruhihgload про то что можно извернуться и сделать master-master репликацию, средствами mysql-сервера. Но тут чуваки реально  гонят, так как любая коллизия порушит к монахам подобную связку, а еще есть deadlock.
Так вот, всякие адепты ruhighload — идите в жопу и играйте в песочнице.

В такой ситуации без полноценного DB-кластера, мы бы просто ходили по минному полю.
Вобщем взяли аккаунт на DigitalOcean, запилили там тестовую площадку и развернули Galera Cluster. В силу врожденной лени, Savage4pro нашел чудоюдософт под названием ClusterControl. Нереальная хрень, с гиперизбыточным функционалом, денег стоит я подозреваю ахулиард, но месяц бесплатного фуллтриала нас полностью устроил. С помощью CC — на голые сервера в три клика накатывается на 90% готовая сконфигурированная система. А потом узлами кластера можно жонглировать как горячими пирожками.

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

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

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

В итоге с такой-то матерью и полным кардбланшем от Динокса, мы завели и отработали тестовую систему и пришло время собирать это дело в бою. Было решено собрать систему в формате web server с nginx и phpfpm, без всяких apache + две реплики базы master-master + небольшой управляющий vps под сервисные нужды.

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

В первые дни Гугл сошел с ума, я так понимаю что он меряет время отдачи контента и сам балансирует нагрузку, которую создают боты. А тут он получил абсолютно стабильные 200мс загрузки страницы. Ну и загружал он, как я показывал на предыдущих графиках по 150-250000 страниц в сутки + нагрузка от посетителей порядка 70-100 000 просмотров + другие боты, я думаю суммарно сопоставимы с гуглом. в итоге 300-500 000 просмотров страниц в день и полет  нормальный.

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

Также мы включили Opcache. Для тех кто не понимает Opcache — это не хранилище для данных, это кеширование исполняемого кода php. В прошлой статье я задавал вопрос. куда делась system — нагрузка, вот ее Opcache и снял.

Сразу после сетапа сервера, которому суждено было стать web-мородой мы на него поставили Munin для мониторинга всего и вся. А сегодня еще прикрутили PHP7.
Я специально оставил этот процесс на сладкое, для того чтобы имея подробную статистику показать вам, да и самому увидеть есть ли от него толк. Таки есть.

Вот вам большой красивый график:

ctoday_cpu

 

Да действительно PHP дает большой прирост производительности. Но друзья мои. У нас здесь только web-сервер, нагруженный, но тут нет базы. Не спешите бежать к вашим вебмастерам с воплями ХОЧУ ХОЧУ ХОЧУ. Если вы для магазина на Opencart поставите PHP7, явной разницы между 5.4 или 5.6, вы не ощутите. В нашем случае это выглядит красиво и дает 10 кратный запас прочности, вместо 6 кратного, который был до этого и это очень круто, так как программой максимум было развернуть систему с нагрузкой в 25%, а тут получились все 10.

Вот еще одна красивая картинка с динамикой событий:

monthly_cpu

 

И еще одна:

nginx_monthly

Небольшой общий faq.

Почему  Galera а не  Percona XtraDB Cluster ?
- потому как базы у нас крутились на MariaDB а Galera — родная так сказать система для нее. 

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

Почему в качестве прокси-прокладки мы не стали использовать MaxScale, а остановились на HaProxy
- несмотря на то что MaxScale также продукт MariaDB foundation, у HaProxy получше система мониторинга — а мониторинг наше все.

Почему dedicated а не облако на том же DigitalOcean?
- потому что физический сервер всегда будет быстрее чем любая виртуализация.

Почему арендованные сервера, а не купить свои — это же дешевле?
- свои сервера хорошо и дешевле, пока вы не посчитали стоимость colocation(стоиомость аренды юнита пот сервер в нормальном дц с хорошим,и каналами считайте половина аренды сервера на Hetzner). С ценой сервантов на Hetzner, да еще минус 19% НДС — итоговая цена аренды — совсем не больно, и мы не привязаны физически ни к хостеру ни к ДЦ. Завтра захочется сменить место дислокации — теряется только месячная абонплата.
будет необходимость увеличить ресурсы, новый узел докупается в один клик и готов к использованию прямо сейчас при этом нет проблем со скоростью коннекта между узлами — у Hetzner очень быстрые внутреннии магистрали как внутри так и между дата-центрами. Почти нет разницы в общем стоят сервера в одной стойке, или в разных ДЦ.
Выпустят послезавтра PHP8 с мегаскоростью работы, отказались от избыточных мощностей — сократили затраты.
А свои сервера — только устаревают и теряют в цене!

Почему мы не масштабировали web-сервер?
- пока что в даной конфигурации присутствует десятикратное резервирование, которого достаточно с головой. 

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

Чем осуществляется мониторинг серверов?
- Munin и встроенные средства CLusterControll

Итог.
Я попытался очень кратко описать детали процесса понятным для большинства языком.
Но кое-что я осозанно пропустил. Во первых — не раскрыл подводные камни связанные с развертыванием системы и способы их обхода, во вторых — не вдавался в технические подробности, потому как Commercial.

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

Я не могу сказать что мы супер-пупер умные перцы. И больше так никто не умеет делать. Это будет полная чушь, так как любая площадка в топ-500 выдачи Яндекса на порядок сложнее.  Но мне кажется у нас получился очень правильный проект и подошли мы к нему не с позиции — лишь бы сделать, а с позиции сделать круто настолько, насколько это возможно, при этом без единого вмешательства в код системы.
И вот тут я должен выразить огромную личную благодарность как Savage4pro, так и Dinox.
Потому что с первым у меня каким то образом получается полное взаимопонимание процессов (ну и как то слишком часто мысли сходятся), и во многом благодаря этому взаимопониманию у нас все получилось, а второй проявил себя очень достойно во всем: от оперативной реакции по его задачам процесса (изменение днс, деплой серверов, конфигурирование форума) до полного вникания во все этапы, но без намека на попытку повлиять на процесс, потому что «где то прочитал». Т.е. все что мы делали, мы делали ровно так и в том виде как мы считали нужным.

——————— Happy end ————-

p.s.

Читать далее

Хуйнаныр(46)Очко(1)

HTTPS HTTPS HTTPS HTTPS HTTPS HTTPS

Слушайте ну это шквал какой то просто.
Мне сегодня человек 20 написали в скайп, который у меня офлайн кстати!

И Мозилла теперь метит сайты незащищенными!

optic_1

optic_2

Так что попробуем собрать все в кучу.

Во первых про перевод есть статья с костылями для 1.5 тут.

Во вторых есть полезнейший мануал, скомпилированный RHCk.

В третьих есть фри мод HTTPS FIX.

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

seohttpsfixpro1

 

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

 

 

 

Хуйнаныр(34)Очко(0)

Оптимизация форума на IPB {экспертиза}

battle

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

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

Так вот имеем вводные. Ресурс на IPB, на котором одновременно онлайн бывает до 600-700 посетителей. 70 000 постов, которые регулярно сканируют боты и совершенно непонятно кем, когда и как настроенный сервер, нагрузка которого валила в 100% без остановки и падала немного только ночью. Доступов у меня нет ни к чему, только к фронтенду, как у банального посетителя.

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

Площадки у нас что forum.opencart.pro, что opencartforum.com, стоят на одном движке IPS (раньше это называлось IPBoard), поэтому некоторое представление о его работе у меня есть.

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

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

Дальше был выбор между APC, Memcache и Redis. Здесь тоже однозначный выбор — исключительно в пользу Memcache, так как работает он быстрее всех.

Также у Ipboard есть механизм popup-сообщений (почти автоддос), механизм внутренней поисковой индексации (почти встроенный сфинкс) и механизма запуска системных событий вызываемый при обращении к фронту а не через крон (можно переключать крон/фронт).

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

Перевели системные процессы на запуск по крону и пытались дождались момента пока закончит перестроение  поисковый индекс (на старом сервере — не вышло, не хватало ему критически ресурсов).

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

Это были даже не полумеры. Это была попытка надышаться перед смертью.
Нагрузка все не хотела падать меньше 80% и при этом так и норовила добежать до 100.

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

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

Но счастье было недолгим. Буквально на следующий день, все 16 ядер процессора оказались опять загружены по полной, и стало ясно, что в такой конфигурации дальше система просто рухнет. Оптимизация «по фотографии» была закончена. Нужно было проводить более подробный анализ, искать бутылочные горлышки, анализировать общий входящий трафик, разбираться со структурой БД и проектировать систему, на которой можно было бы оживить проект. К сожалению даже десяток самых быстрых VPS от AdminVps  мало чем помог.

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

А  пока вот вам красивая картинка (здесь нет данных по первоначальнй площадке):

cpu_op_f

 

Первый кто правильно скажет куда делась нагрузка system(зеленый график), получит от меня 1000 рублей, там как раз завалялось с донатов.

Хуйнаныр(41)Очко(0)