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

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

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

barabara

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

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

to be continued….

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

Быстрые магазины, кеши, 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 — таки дерьмо! Но на свои деньги — это просто бриллиантовый бриллиант.

 

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

Со дна постучали или новая оооочень критичная уязвимость в дополнениях

vir

Пока я тихо спокойно отходил от нового года и потихоньку пилил наш уже полусекретный проект, со дна постучали!

Я говорил, что модули с автообновлением с сервера — это зло!
Я говорил, что хранить фтп в базе — это зло!

Ну вот, получайте.

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

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

Что делать дальше с фтп — я думаю не надо рассказывать. Сначала угоняется ваша база и переводиться удаленно на другой сервер. Потом, когда у вас не будет бекапа, удаляются все данные, и у вас не остается ничего. Это самый плохой вариант.

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

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

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

Но молчать тоже нельзя.

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

Заходите — пользуйтесь.

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

Если кто не верит, но ваш сайт не прошел проверку — пришлите мне его адрес в личку на форуме, я  вам пришлю в ответ ваш ftp-пароль.

Но честно говоря — это полный писец.

==============================================================================

UPD1:
С автором модулей, человек который обнаружил уязвимость ведет переговоры. Автор божится что его взломали, раскодировали его модули и закодировали опять. И выложили у него же на сервере.
Во первых — так не бывает.
Во вторых, ну что это за автор модулей, которого ломают.
В третьих я уже писал, любые механизмы доступа на сервер в обход веб-мастера, это дыра!
==============================================================================

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

==============================================================================

UPD3:
Я пошел спать, напомните Диноксу кто-нибудь, чтобы он когда закончит обновление форума своего, сделал рассылку по своим пользователям со ссылккой на чекер, по моим прикидкам заражено более 1000 магазинов.

==============================================================================

UPD4:
Каменты в блоге переведены в режим премодерации. Пишите, скоро вернусь и все проапрувлю.

==============================================================================

UPD5:

Человек, который нашел уязвимость  — спросил автора, возможно у него есть мысли какие на этот счет и он готов выплатить Bug Bounty.

Ответ просто — сказочный:

debil_2

==============================================================================

UPD6:

Автор дополнений пришел в каменты и ноет — как считаете — дать ему слово, или послать ?

==============================================================================

UPD7:

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

UPD8:
Написал статью с подобным разбором полетов.

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

Тормозит Opencart часть 15 | Наследие упырей

bikegirl

Сначала анекдот.

Приходит хирург кардиолог к автомастеру, двигатель мол кряхтит — посмотри.
А болторез давай ныть.
— Почему мол ты получаешь 5000 долларов за операцию, а я 500 за капитальный ремонт движка?
Хирург завел двигатель и говорит — «на ремонтируй, я тебе заплачу 5000″.

Век живи век учись.

Я недавно заглядывал в Престу, 2 000 товаров, тормозит как скотина. Вроде бы все инструменты есть для аудита в ней встроенные. А с налета сделать ничего не смог. Пришлось бы переписать полдвижка. С Опенкартом же, уже давно все понятно. Мой первый пост про тормоза Opencart появился почти два года назад в январе 2014 го, с того времени магазинов в лицо и изнутри я поведал наверное штук 600 уже, и 99% стали работать зашибись.

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

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

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

Вот тут я подзавис. Так как доступа к сереверу у меня нет. VMOD нет. PhpMyAdmin на сервере нет. Профайлера под 1.4 у меня нет. А если бы и был. У владельца магазин — он же CRM и укладывать его даже на полчаса нельзя.
На помощь пришел мод фрилансера, который db_log под 1.5, хорошо что в 1.4 и 1.5 библиотека db.php не сильно отличается или не отличается совсем. Очень быстро лог медленных запросов перевалил за пару мегабайт и было над чем работать.

И у нас обнаружилась вот такая конструкция

SELECT * FROM oc_product ……. ORDER BY RAND() LIMIT 0,3

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

И так 10 раз по 500 миллисекунд на выполнение запроса. А трафла на магазине в пик человек 20-30 в минуту. Вот они зашли и выгрызли весь ресурс у mysql.

Плюс 5 секунд загрузка главной (которая якобы не оптимизируется и меняйте движок) — это овердохуя.

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

SELECT product_id FROM oc_product ……. ORDER BY RAND() LIMIT 0,3

Потом перебираем получившийся массив, через model_catalog_product->getProduct($product_id) получаем полные данные по нашим трем товарам. И на выходе получаем 250мс полную генерацию страницы.

Четыре специалиста. Порядка 500 долларов в труху потраченных на их услуги-заслуги. И решение, которое лежит на поверхности.

По моему это уже старость. И мне пора устраиваться Juniorom в 1С.

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

Знаете, херня в жизни случается

muzhik-bleat_44430101_orig_

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

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

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

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

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

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

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

Реквизиты для помощи:
Приват Банк Гривны — 5168 7556 3318 0266 — Горбач Александр Петрович
Приват Банк Доллар — 5168 7573 0919 8945 — Горбач Александр Петрович
Приват Банка Евро 5168 7573 0919 8911 — Горбач Александр Петрович
Unikredit Bank Гривны — 4874 1054 0223 0074 — Горбач Александра Владимировна

Кошельки вебмани
Гривна U237883635041
Рубли R103994560503
Доллар Z376064367043
Евро E227571332910
Яндекс 410013111425322

Как говорится, с миру по нитке голому рубаха — а Ромке жизнь.

p.s Кто такя Блонди, если кто не знает — это наша боевая подруга, которая любит вертеть хвостом и принимает активное участие в нашем коммьюнити, направляя и наставляя регулярно полезными советами новичков и не только. Вот ее профиль у Динокса,  а вот у нас.
p.s.s К чему я написал столько воды а не просто дал реквизиты и диагноз мелкого. Ну знаете ли… Это ж мой блог. Вы ко мне привыкли и такая вот у меня подача. Основная мораль — очень проста….
Бабло приходит и уходит. А будет ли у меня за что уважать себя лет в 60, для меня очень важно!

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

Идеальный SEO модуль для Opencart

seo_modul

Что хотят все владельцы магазинов?

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

Все слышали это волшебное слово СЕО СЕО СЕО, его слышали и гавно-разработчики студенты с fl.ru и иже с ними.

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

В свое время господин Yesvik и Snastik сделали для сборки Ocstore за месяц, больше чем весь остальной осТим за все время. И это был процесс по созданию SeoPro. Ни до ни после. никто не смог реализовать более изящно задачу устранения дублей страниц в  Opencart.

Потом появился сеопак про, потом какой то дебил сделал Палладин Менеджер, это ж блять школоло — Палладин блять  Уж лучше бы сделал Бабушкины-засранные-трусы-про2-сео-менеджер.  Эти приблуды напиханы кучей функционала, но они больше калечат и тупят магазин чем, приносят пользу.

Так вот господа, давайте обсудим. Какие функции должны быть у идеального сео-модуля для Opencart?

Читать далее

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

Оживаем потихоньку. Бабуля приехала. Пирожков привезла.

dancing-baby-groot-comic-strip

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

Так что  пришло время разморозить бложик и выдать вам порцию свежачка.

Читать далее

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

Месяц хостинга бесплатно от ADMINVPS. Бабушка принесла новогодних ништяков.

adminvps.pngadminvps.png.ca2ac6a480cc986cf7adffcfa29

PARTNER2015 — минус 60% на новые заказы хостинга или VPS (с платежным циклом 1 месяц) +1 месяц бесплатно к услуге, если сайт перенесен от другого хостинг-провайдера.

Для получения скидки:
1. Оформить заказ нужной услуги с обязательным применением промо-кода на скидку.
2. Оплатить выставленный счет.
3. Обратиться в отдел техподдержки, чтобы перенесли сайт.
4. После успешного переноса написать в отдел продаж с просьбой начисления дополнительного месяца.


SERVER700 — минус 700 руб при покупке выделенного сервера (не путать с VPS).

Для использования нужно применить промо-код в процессе оформления заказа.

Внимание! Промо-коды действительны с 15.12.2015 по 31.12.2015 включительно.

Время активации и остановки промо-кодов — в 00.00 по Московскому времени.

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

Секс по телефону с заказчиками. Все за и против

1365492018-bezrabotnyj-anglichanin-istratil-na-seks-po-telefo

Меня постоянно преследует две идеи от заказчиков — первая дайте ваш телефон созвонимся. Вторая давайте встретимся в офисе у вас у нас.

Мне вот интересно, людям не хуй делать. Ездить, чаи распивать пиздеть хуй пойми о чем, на секретарш вяло мять яйца потихому?

Что это за пережитки голодных 90х, когда колбаса была по 2.20 и в тырнетах еще можно было срезать негламурную подругу, которая от души могла дать с первого раза.

Почему народ не ценит свое время, и считает, что все вокруг делают так-же.

Читать далее

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

Новости от хостеров строго 18+

rasstrelyat-ih-vseh-nahuy_45105697_orig_

Пришла вот такая жалоба нашему армянскому радио:

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

Вроде бы все верно.
А теперь смотрим с другой стороны, у нас проект. В который инвестировано 10 000 долларов. Мы качаем рекламы еще на 300 в день, и зарабатываем 500-600.

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

Переносят парни все вручную, естественно по пизде идут все права на папки, магазин ложится. И начинается классическая возня — я не я хата не моя, идем в ногу со временем.

ТУПЫЕ БЛЯДИ. ТАК РАБОТАТЬ НЕЛЬЗЯ. Вы продали клиенту серверное окружение. Руки прочь суки от настроек. Хотите что-то добавить делайте это опционально или по согласию с клиентом. Или же так, чтобы никто ничего не заметил. Не можете — идите бляди улицы подметайте.

Под катом видеоинструкция по применению таких хостеров.

Читать далее

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

Обновление до версии OCSHOP 2.1.0.1.2

zlo_ico

В версии CMS:
1. Исправлен баг с блогом о котором идет речь в этом сообщении

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

В версии PRO:
1. Вошли изменения версии CMS
2. Новый модуль Custom Footer
3. Новый модуль Custom Banner

Все купившие OCSHOP.PRO могут получить Бесплатные обновления на http://liveopencart.ru/

Для новых покупателей с сегодняшнего дня цена составляет 150 рублей.

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

Релиз OCSHOP.CMS 2.1.0.1

ocshop_2_1_0_1
Несколько часов назад вышел релиз OpenCart 2.1.0.1 в свою очередь мы рады представить вам OCSHOP.CMS 2.1.0.1 ознакомиться с возможностями можно тут.
Как вы можете заметить отличий в PRO и CMS версии на данный момент нет но про версия является платной и на сегодняшний день стоит 50 рублей :-) кстати купить можно тут. Скачать бесплатную версию можно тут.
Читать далее

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

SEO-Аудит и оптимизация магазина бесплатно. Напиши комментарий и получи $250

ded

«Мой дед говорит, делай добро и бросай его в воду».

Мы делали делали делали Ocshop  и сделали.

На сегодня, нашей сборкой пользуется более 40 000 человек. Если вдуматься в масштабах территории — это такой себе плотнозаселенный ПГТ, или небольшой город. С точки зрения мировой революции — мизер, но с точки зрения личного достижения — большой успех.

Без вас, без обратной связи, без активных участников форума — мы бы этого всего никогда не сделали.

Так что спасибо вам.

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

Для того чтобы оказаться в числе избранных вам достаточно в комментариях к этому посту до 10 октября сделать небольшой анонс своего магазина и вкратце рассказать как вы очутились на этой подводной лодке. Избранного выберем либо через random.org, либо я на свое усмотрение по одному мне известным критериям. Реальная цена пакета услуг — $250.

Так что на старт внимание, велкам!

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

Нужна помошь зала.

0G9B_ckZQ6M

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

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

Но вот в данный момент уже две недели происходит HARD ВJoB, поэтому ни единой идеи, чем бы вас повеселить.

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

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

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

UNIVERSAL.OCSHOP.PRO 1.5.6.4.1

universal
Доступен для OCSHOP.CMS 1.5.6.4.1 и OCSHOP.PRO 1.5.6.4.1
Сравнение возможностей доступно по ссылке http://universal.ocshop.pro/overview/
Демонстрация:
OCSHOP.PRO 1.5.6.4.1
OCSHOP.CMS 1.5.6.4.1

Купить Pro версию
Скачать Lite версию

Ранее купившим OCSHOP.PRO шаблон доступен для скачивания в вашем личном кабинете.

Так же напоминает что доступны купоны для скидки в этой теме http://ocshop.info/easy-ocshop-pro-1-5-6-4-1/

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

EASY.OCSHOP.PRO 1.5.6.4.1

easy_pro
Это дополнительный шаблон для OCSHOP.PRO

Ознакомиться с возможностями вы можете по ссылке: http://easy.ocshop.pro/overview/
Демонстрационный магазин доступен по ссылке: http://easy.ocshop.pro/
Демонстрация административной части доступна по ссылке: http://easy.ocshop.pro/admin (demo\demo)

Купить можно тут: http://liveopencart.ru/opencart-moduli-shablony/moduli/prochee/ocshop-pro-1-5-6-4-1

Ранее купившим шаблон доступен бесплатно на http://liveopencart.ru/
Для новых покупателей предусмотрены скидки:
10 1 купонов для получения скидки 50% при применении купона стоимость составит 3500 р. код купона quicken
20 купонов для получения скидки 30% при применении купона стоимость составит 5000 р. код купона deckmeout

Для использования купона на скидку введите его при оформлении заказа.

После приобретения свяжитесь с  администратором для получения статуса про пользователя, по ссылке: http://forum.ocshop.info/index.php?/user/1-admin/
Для получения последующих лицензий свяжитесь с администратором , по ссылке: http://forum.ocshop.info/index.php?/user/1-admin/
Техническая поддержка OCSHOP.PRO осуществляется на форуме: http://forum.ocshop.info/

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

ИЩУТСЯ ПЕЙСАТЕЛИ МОДУЛЕЙ

wanted

Бабушка вам принесла хороший новостей мешок.

Если вы пишите хорошие модули, вас достали клиенты — мы хотим версию под OCSHOP, но один известный ресурс блокирует подобные дополнения, выход есть.

Уже давненько существует неплохая торговая площадка

logo19

 

На которой вы совершенно спокойно можете выкладывать любые дополнения под нашу сборочку. Господин 19th19th ждет вас в гости.

Мы же в свою очередь создадим тему для поддержки вашего дополнения на http://forum.ocshop.info

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