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

rabbit

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

Те кто меня постоянно читают, знают что я сделал целую серию постов «тормозит 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)

Запостить высер

Стучать мне на мыло
avatar

Сортировать:   Свежие | Тухлые | Хуйнанырные
Nameless
робот-вертер
Nameless
1 месяц 8 дней назад

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

Nameless
робот-вертер
Nameless
1 месяц 8 дней назад

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

Waha
робот-вертер
Waha
1 месяц 8 дней назад

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

Ginger Dog
робот-вертер
1 месяц 7 дней назад

Эх, так хорошо начал. Мысли умные и слог хороший. Даже уважать начал. А закончил как обычно, матом и грязью и все обояние умных слов слетело.

Ольга
робот-вертер
Ольга
1 месяц 7 дней назад

Бриллиантовый бриллиант — в мемы.
Как всегда, много полезного и ржака, спасибо)

kopaweb
робот-вертер
kopaweb
1 месяц 7 дней назад

Отлично. Я как-раз один из тех кого описали в статье. Недавно переехал более мощный сервер, но сайт не стал работать быстрее. Начал немного оптимизировать в силу своего ума. Магазин у меня на ocStore 1.5.5.1.2. Какую версию php лучше использовать?

noVe
робот-вертер
noVe
1 месяц 7 дней назад

Классно. Спасибо. Жаль, что только половину понял :)
Подскажите, а что за фильтр ведьмы? На вашем форуме его часто рекомендуют — как понимаю он будет получше ocfilter и filter pro. Если несложно, сбросьте на него ссылку.

Автор камента сцыкло
робот-вертер
Автор камента сцыкло
1 месяц 7 дней назад

sv2109 ещё то хуйло! Парсеры зло, content downloader и импорт/экспорт в помосч!

uncleric
робот-вертер
uncleric
1 месяц 6 дней назад

Ох ты ж блин, я осилил прочитать столько букв! :)

rb
робот-вертер
1 месяц 5 дней назад

От прикручивания поддержки CDN к опенкарту иногда есть толк: возможность разложить проект на два сервера. Быстрый, с памятью и SSD, но не очень большой (для PHP и MySQL) и помедленней, но для картинок (на сотни гиг или терабайт, скажем). То есть необязательно рассматривать CDN только с точки зрения производительности. Иногда оно может неплохо сэкономить денег стартующему проекту.

Vladzimir
робот-вертер
Vladzimir
1 месяц 4 дней назад
Некоторые приведенные моменты — тухлые. Например кеш мускуля — херня, по причине того что в условиях опенкарта он практически ни как не может использоваться а тот кеш который генерится не может инвалидироваться из-за «современной архитектуры». По моим наблюдениям, при отключении кеша мускуля скорость генерации страницы вырастает на 20%. Файловый кеш VS memcache — разница то как раз есть, поскольку в файлах данные еще лополнительно энкодятся, а в мемкеш можнос засовывать массивы и так. Кеш СЕО-про дешевле всего засовывать в php файл в виде готового массива с последующим инклудом. Быстро, но поджирает немного памяти. А вообще опенкарт в плане ЧПУ —… ЧЕТАТЬ ЕСТЧО
rb
робот-вертер
1 месяц 4 дней назад
По сеопро — как всегда, 2 варианта: или как сейчас в url_alias + join-ы или денормализация и хранить готовый ЧПУ в таблицах товаров, категорий и т.п. Но тогда в 10 раз внимательней их перегенерировать при обновлениях и редактировании категорий, например. Об этом ещё в 11-12 годах заходил разговор. Всё упирается в то, что кому это нафиг надо за бесплатно морочиться в 10 раз больше? Когда в 99% магазинов сойдёт и более простой вариант. А так — никто ж не мешает сделать лучше. Снастик попросил — Yesvik сделал. На шару и для всех. Десятки тысяч осчастливив на долгие годы. Если подрос… ЧЕТАТЬ ЕСТЧО
Марк
робот-вертер
Марк
1 месяц 3 дней назад

Да в seo_pro неудачная реализация кеширования, учитывая что формирование ЧПУ идет в основном «потоком» и при большом количестве товаров и категорий json_decode штатного кешировщика opencart просто ставит в ступор весь сервер
И второе … при большом количестве категорий путь надо рассчитывать при создании категории и хранить в БД, не динамически его все время «считать» (я экспериментировал на seo_pro — прирост просто колоссальный (в три-пять раз быстрее) когда более 300 категорий и более 10k товаров)

web-mehanik
робот-вертер
web-mehanik
1 месяц 2 дней назад

сталкивался с louise-какие-то_цифры, чувак дело говорит

artembalt
робот-вертер
artembalt
27 дней 12 часов назад

«красит губы буржуйским модулям и выдает их за свои»
яржунимагу, спс

wpDiscuz